JDBC实战：连接管理、预编译、事务与批处理优化指南

JDBC这玩意儿，说简单是真简单，说复杂也真复杂。很多人写了好几年Java，天天用MyBatis、Spring Data JPA，结果遇到个连接泄漏、预编译失效、事务不回滚的问题，照样一脸懵。原因很简单——框架封装得太好了，把JDBC的细节全藏起来了，但底层跑的依然是JDBC那一套东西。

我最近在帮某公司做一套订单中台系统，里面有个账务模块要对接MySQL，对性能和事务要求都比较高。刚开始我也直接用JPA，但跑了段时间就发现批量写入慢得离谱、偶尔还有死锁。后来痛定思痛，把底层JDBC链路重新撸了一遍，从连接管理、PreparedStatement预编译到批处理和事务隔离级别，逐个优化，整体性能提升了好几倍。这篇就把这些实战经验和踩过的坑完整写出来，适合正在学数据库编程的Java初学者，也适合那些用框架用得顺手但对JDBC底层一知半解的开发者参考。

1. 内容整体设计与思路拆解

1.1 JDBC在Java技术栈里的真实位置

JDBC的全称是Java Database Connectivity，翻译过来就是Java数据库连接。它本质上是Sun公司（现在是Oracle）定义的一套统一访问关系型数据库的接口规范，接口在JDK里，实现由各数据库厂商提供，比如MySQL的驱动是mysql-connector-java（现在叫com.mysql:mysql-connector-j），Oracle的驱动是ojdbc系列，PostgreSQL的有postgresql驱动。

这套设计的核心思路是：不管底层是什么数据库，开发人员只需要面向JDBC统一的接口编程，就能完成“连接数据库、发送SQL、处理结果集”这些操作。换数据库厂商的时候，只需要换驱动jar包和连接URL，业务代码几乎不用改。

很多初学者容易陷入一个误区：既然现在都用MyBatis或Spring Data JPA，是不是JDBC就不用学了？这个想法我当年也有过，但实际工作中碰过几次壁就明白了。框架只是对JDBC做了封装，它的底层依然是Connection、Statement、ResultSet这些原生接口。遇到SQL性能瓶颈、连接池参数调优、分布式事务等进阶问题，不懂JDBC原理根本无从下手。JDBC不是“过时技术”，而是Java数据库编程的地基，地基不稳，上面盖什么楼都悬。

1.2 为什么框架满天飞的今天，还要手写JDBC

有人会问：“有MyBatis了，谁还写JDBC啊？”这个问题问到了关键处。确实，项目里几乎不用手写JDBC代码，但理解JDBC范式仍然是必要的，原因有三：

第一，框架的灵活边界有限。MyBatis的SQL映射确实方便，但遇到极其复杂的动态SQL、游标批量处理、自定义数据库函数调用时，框架的写法反而别扭，不如直接走JDBC干净。

第二，排查问题需要底层视角。比如MyBatis报了个“Too many connections”，不理解连接管理机制，你连从哪儿查起都不知道。曾经某项目连接池设置最大连接数是20，但数据库侧仍然出现连接数超限，底层排查后发现是某业务线程池内的任务在无限取得连接却没归还，这类问题用框架日志很难暴露，归根到底还是JDBC连接生命周期管理的问题。

第三，性能调优绕不开JDBC。SQL优化、批处理参数rewriteBatchedStatements、结果集流式读取、事务隔离级别调整，这些操作都是JDBC层面的能力，框架暴露出来的只是冰山一角。想要真正把数据库读写性能调到极致，必须有原生JDBC的底子。

1.3 技术选型的权衡：什么场景直接用JDBC，什么必须用框架

技术选型没有绝对的好与坏，只看场景适不适合。我的习惯是这么权衡的：

日常业务CRUD、多表关联查询、动态条件组合，用MyBatis或JPA这样的ORM框架，开发效率高，代码可读性也好。复杂的批量数据同步、ETL操作、报表查询、需要精细控制游标和内存的场景，我倾向直接用JDBC原生API，控制力最强，不会因为框架的自动映射损耗性能。涉及分布式事务、多数据源路由、分库分表这类架构级需求，一般用ShardingSphere这类中间件，但它们的底层依然依赖JDBC的数据源抽象，理解JDBC能帮你更快看懂中间件源码。

一句话总结方案选择的逻辑：框架解决的是80%的常规需求，剩下的20%特殊场景，学透JDBC才有能力亲自上。很多人说“框架替代了JDBC”，其实是偷懒的说法，JDBC从来没有被替代，只是被包了一层又一层。

2. 核心细节解析与实操要点

2.1 连接管理：Connection不是new出来的，是拿出来的

先看看JDBC的第一步——建立连接。最原始的写法是调用DriverManager.getConnection()，但这个思路在真实项目中基本活不过第二周。因为每次getConnection都会创建一个物理连接，频繁创建和销毁对数据库的压力很大，数据库握手、鉴权、TCP建连都是昂贵消耗。生产环境的标准做法是使用连接池，让连接复用。

连接池选型上，Druid、HikariCP、C3P0是市面主流的几款。我现在基本无脑选HikariCP，原因就一个字：快。它的字节码级优化做得很到位，号称“光速连接池”，Spring Boot 2.x之后也默认使用它。核心配置参数如下：

spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 idle-timeout: 300000 connection-timeout: 20000 max-lifetime: 1800000 pool-name: OrderHikariPool

这里特别注意两个坑：

max-lifetime必须小于数据库侧的wait_timeout。比如MySQL默认的wait_timeout是8小时，如果你把max-lifetime设成8小时以上，连接池里的连接会在数据库侧被回收，而连接池还傻傻地认为连接有效，下次使用时直接抛异常。我建议max-lifetime控制在数据库超时时间的80%左右，比如数据库wait_timeout是28800秒（8小时），max-lifetime就设1800000毫秒（30分钟），留出足够的冗余。

连接数不是越大越好。很多新手把maximum-pool-size调到50、100甚至更多，觉得并发就上去了。但数据库的连接数是有限资源，每个连接都要占用内存和线程资源，连接数太多反而引发线程上下文切换和锁竞争，性能断崖式下跌。经验公式是：连接数 = 核心线程数 × (平均响应时间 / 平均RT时间 + 1)，具体数值要靠压测来确定，一般几十并发的小服务，20个连接绰绰有余。

2.2 Statement与PreparedStatement：不仅仅是拼字符串的区别

JDBC执行SQL有两种基础方式：Statement和PreparedStatement。初学者常觉得它们无非是接口不同、写法不同，实际差距非常大，我先上一个对比表格：

我在实际项目里几乎不写Statement，一律用PreparedStatement。原因就一条：安全性。SQL注入是最常见的攻击手段，字符串拼接用户输入进SQL，等于把数据库大门钥匙交给了攻击者。PreparedStatement用了占位符?和预编译机制，参数值不参与SQL语法解析，从机制上杜绝了注入的可能。

再说一个容易忽略的性能细节：MySQL默认开启了预编译缓存吗？没有。即使你写了PreparedStatement，如果驱动参数没配好，每次执行还是会把完整SQL发给数据库重新解析。

看这个经典参数：

// MySQL JDBC URL中加上预编译缓存 String url = "jdbc:mysql://localhost:3306/order_db?useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=500&prepStmtCacheSqlLimit=2048";

useServerPrepStmts=true表示启用服务端预编译，cachePrepStmts=true开启预编译缓存，prepStmtCacheSize设置缓存条数。这几个参数不配，PreparedStatement的性能优势根本发挥不出来，走了服务端预编译之后，相同SQL重复执行时，数据库侧能直接命中缓存的执行计划，省掉SQL解析和优化的一大部分开销。

2.3 ResultSet：处理结果集时最容易翻车的地方

执行完查询SQL之后，数据以ResultSet的形式返回。很多人以为ResultSet就是一张“表”，一次性把数据全放内存里，其实不是这么简单。

ResultSet本质上是一个游标对象。开始时它指向第一条记录之前，调用next()方法光标才会向下移动一行，返回true表示这一行有数据，false表示没有更多行了。一开始写代码时觉得这种“流式访问”很反直觉，跟Python那种拿列表的方式完全不同，后来才体会到这种设计的精妙——大数据量下，游标模式可以配合流式读取，一行处理一行，不需要把全量结果集塞进内存。

ResultSet还有一个常见的误区：获取列值的时候，可以用列名也可以用手标号，推荐优先使用列名。别问为什么，别问为什么能看懂代码的人有多重要。

// 推荐写法 String userName = rs.getString("user_name"); // 不推荐写法 String userName = rs.getString(2);

如果你用列索引，SQL稍微加一个字段、调整一下查询列顺序，代码里的数字就全对不上了，排查起来要命。用列名虽然多敲几个字符，但可读性和维护性完全不同。

处理大数据量查询时，还有个调优方向值得注意。默认情况下，MySQL驱动会把查询结果一次性全量拉到客户端内存，如果一次查了几十万条数据，很容易直接OOM。此时可以把查询设置为流式读取：

// 关键是设置fetchSize为Integer.MIN_VALUE preparedStatement.setFetchSize(Integer.MIN_VALUE);

这个设置会让驱动采用逐行读取的方式，每次只从服务器取一部分数据到本地，内存占用大幅下降。但要注意，这种模式下连接会被该查询长时间占用，期间不能再跑其他查询，查完必须立刻关闭语句释放连接。流式读取适合做大数据量的导出任务，不适合高频交互场景。

3. 实操过程与核心环节实现

3.1 手写第一个完整的JDBC增删改查模块

理论铺垫完毕，下面直接上实操。我用一个最典型的“用户订单模块”来演示CRUD全流程。先准备数据库表：

CREATE TABLE `user_order` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '订单ID', `user_id` BIGINT NOT NULL COMMENT '用户ID', `order_no` VARCHAR(64) NOT NULL COMMENT '订单号', `amount` DECIMAL(10,2) NOT NULL COMMENT '订单金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已取消', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户订单表';

对应的实体类，我直接省掉Lombok注解，写纯Java版本：

public class UserOrder { private Long id; private Long userId; private String orderNo; private BigDecimal amount; private Integer status; private LocalDateTime createTime; private LocalDateTime updateTime; // getter/setter 略 }

连接获取和关闭这一块，强烈建议统一封装工具类。我见过太多项目每个DAO类都重复写“Class.forName、getConnection、finally里close”这种样板代码，不仅啰嗦，还容易出现资源泄漏。一个标准的封装长这样：

public class JdbcUtil { private static HikariDataSource dataSource; static { HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/order_db?useUnicode=true&characterEncoding=utf8&useServerPrepStmts=true&cachePrepStmts=true"); config.setUsername("root"); config.setPassword("123456"); config.setMaximumPoolSize(20); config.setMinimumIdle(5); config.setConnectionTimeout(20000); dataSource = new HikariDataSource(config); } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } public static void close(AutoCloseable... resources) { for (AutoCloseable resource : resources) { if (resource != null) { try { resource.close(); } catch (Exception e) { // 关闭失败通常不影响主流程，记录日志即可 } } } } }

工具类设计上有一个关键点：获取连接的入口统一走连接池，绝不直接new DriverManager获取。同时close方法用AutoCloseable可变参数，把Connection、Statement、ResultSet一次性关闭，避免遗漏。这里特别强调，关闭顺序必须是ResultSet先关、Statement其次、Connection最后，反着关会报错或者造成资源无法释放。

接下来写DAO层，完成插入订单操作：

public class UserOrderDao { public int insertOrder(UserOrder order) throws SQLException { String sql = "INSERT INTO user_order(user_id, order_no, amount, status) VALUES(?, ?, ?, ?)"; try (Connection conn = JdbcUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setLong(1, order.getUserId()); ps.setString(2, order.getOrderNo()); ps.setBigDecimal(3, order.getAmount()); ps.setInt(4, order.getStatus()); return ps.executeUpdate(); } } public UserOrder findByOrderNo(String orderNo) throws SQLException { String sql = "SELECT id, user_id, order_no, amount, status, create_time, update_time FROM user_order WHERE order_no = ?"; try (Connection conn = JdbcUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, orderNo); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { UserOrder order = new UserOrder(); order.setId(rs.getLong("id")); order.setUserId(rs.getLong("user_id")); order.setOrderNo(rs.getString("order_no")); order.setAmount(rs.getBigDecimal("amount")); order.setStatus(rs.getInt("status")); order.setCreateTime(rs.getTimestamp("create_time").toLocalDateTime()); order.setUpdateTime(rs.getTimestamp("update_time").toLocalDateTime()); return order; } } } return null; } }

注意我把try-with-resources用到了极限——Connection、Statement、ResultSet全部写在try括号里，这样JVM会自动帮我们关闭资源，连finally代码块都不用写了。Java 7之后这个语法是标配，还在手写finally的人该更新习惯了。

3.2 事务控制：手动管理自己的提交和回滚

JDBC默认在autocommit模式下运行，也就是每条SQL执行完自动提交，事务边界跟着单条SQL走。这满足不了多个操作必须同时成功或同时失败的业务场景。比如用户下单后要同时扣库存和生成订单，扣库存成功但生成订单失败，就出现了数据不一致。所以必须手动控制事务。

打开事务的方式是把autocommit关掉：

public void createOrderWithTransaction(UserOrder order) throws SQLException { Connection conn = null; try { conn = JdbcUtil.getConnection(); conn.setAutoCommit(false); // 开启手动事务 // 业务操作1：插入订单 insertOrder(conn, order); // 业务操作2：扣减库存 deductStock(conn, order.getUserId()); conn.commit(); // 都成功了，统一提交 } catch (SQLException e) { if (conn != null) { try { conn.rollback(); // 任何一个失败，全部回滚 } catch (SQLException ex) { log.error("回滚失败", ex); } } throw e; } finally { if (conn != null) { try { conn.setAutoCommit(true); // 恢复默认状态 conn.close(); } catch (SQLException e) { log.error("关闭连接失败", e); } } } }

这里有两个细节容易被忽略：

事务期间的Connection绝对不能放在try-with-resources里自动关闭。因为在commit之前如果连接被关闭了，事务就被隐式回滚，业务还没执行完呢。Connection必须手动控制生命周期，等到所有事务操作都完成后再关闭。

finally里恢复setAutoCommit(true)是个好习惯。连接池里的连接是被复用的，如果不恢复autocommit状态，下一次从池里拿出这个连接时仍然处于手动事务模式，后面所有操作都不会自动提交，数据悄悄丢失不说，排查起来非常痛苦。我在这上面栽过一次，后来所有的连接归还前都必须重置状态。

关于事务隔离级别，MySQL默认是REPEATABLE_READ（可重复读），一般业务场景不用动。但在某些高并发场景下，比如要防止幻读的账务结算，可以单独调整：

conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);

注意，事务隔离级别的调整必须在事务开启前设置，事务进行中改隔离级别会直接抛异常。另外，调整隔离级别会释放该连接上的所有锁，如果有正在执行的SQL会受影响，不建议在运行中的热点事务上动态切换。

3.3 批量操作：别一条条insert，那是一万倍的速度差距

批量插入是JDBC里提升性能最明显的一招。先看反面教材，循环10万条插入数据，每条单独prepareStatement+executeUpdate，这种写法慢到让人怀疑数据库是不是坏了。因为每条SQL都要独立经历网络往返、SQL解析、事务提交（在autocommit模式下），开销全耗在“路上”了。

正确姿势是使用批量模式：

public void batchInsert(List<UserOrder> orderList) throws SQLException { String sql = "INSERT INTO user_order(user_id, order_no, amount, status) VALUES(?, ?, ?, ?)"; try (Connection conn = JdbcUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { conn.setAutoCommit(false); int batchSize = 500; int count = 0; for (UserOrder order : orderList) { ps.setLong(1, order.getUserId()); ps.setString(2, order.getOrderNo()); ps.setBigDecimal(3, order.getAmount()); ps.setInt(4, order.getStatus()); ps.addBatch(); count++; // 每500条执行一次批次，防止批量数据积压内存 if (count % batchSize == 0) { ps.executeBatch(); } } ps.executeBatch(); // 执行剩余批次 conn.commit(); } }

batchSize不是越大越好。每条batch都会在内存中暂存，太大容易造成PreparedStatement的临时数据积压，同时也加大了单次提交的事务粒度，一旦失败回滚范围更大。经验表我放出来：

从这里也能看出来，批量操作和事务控制是联动的——批量插入必须关闭autocommit，否则执行批次后的每条SQL仍会单独提交，批次的性能优势全被浪费了。

使用MySQL还有个大招，就是开启rewriteBatchedStatements参数。这个参数的作用是，让驱动把多条INSERT语句重写成一条多VALUES的INSERT，一次性发给数据库。比如原来发5万条INSERT，开启后可能变成几百条批量INSERT请求，网络传输和解析开销直接下降一个量级：

String url = "jdbc:mysql://localhost:3306/order_db?rewriteBatchedStatements=true";

我在做账务明细批量初始化的时候，就是把rewriteBatchedStatements打开、batchSize设1000，插入10万条数据从原来的80多秒压缩到3秒左右，体感提升非常夸张。但这个参数对UPDATE、DELETE没有优化效果，它只针对INSERT，别指望一把梭全场景提速。

3.4 连接池选型实战：HikariCP还是Druid

连接池选型是JDBC实战绕不开的决策点，市面选择看起来很多，真正在生产的也就HikariCP和Druid两个主流阵营。

HikariCP的优势是性能极强、轻量，Spring Boot默认集成，占用资源小，适合绝大多数互联网应用场景。Druid的优势是功能丰富，自带监控面板、SQL防注入过滤、慢SQL统计，适合需要可视化监控和审计的团队。如果你的系统对性能要求高、团队对监控面板不依赖，无脑选HikariCP；如果你需要操作审计、敏感SQL拦截、墙上的监控大屏，Druid更合适。

连接池的选择不是越复杂越好，而是越贴合业务越好。我常和团队说的一句话是：连接池是你系统与数据库之间的“水管”，水管太细会堵，太粗浪费材料，关键是算准流量再定管径。拿HikariCP配置举例，比较稳妥的起步参数就是上文那个表格里的，然后通过压测接口TPS和RT逐步微调数值。

还有一个必查参数：连接池的初始化和预填充。HikariCP有initializationFailTimeout和minimumIdle配置，前者表示启动时如果获取不到连接是否快速失败，后者控制最小空闲连接数。生产环境建议把初始化失败快速打开，避免服务已启动但数据库连不上导致后续请求全部5xx，宁可启动失败也别半死不活。

4. 常见问题与排查技巧实录

4.1 “Too many connections”：连接泄漏的经典阴谋

这个错误信息见过无数次。字面意思是数据库的连接数达到上限，但根本原因多半不在数据库，而在应用侧没有正确关闭连接。连接池里的连接是有限的，你从连接池拿了一条不归还，连接池里的可用连接就少一条，等所有人都不归还，连接池耗尽，新请求就全部卡死。

典型的泄漏场景有这么几种：

第一种是在业务代码里只关闭了ResultSet或Statement，偏偏忘了关闭Connection。比如用finally块的时候只关了ps和rs，Connection漏了。第二种是异常路径上提前return，Connection没走到close代码。第三种是用完连接池连接后调用了conn.close()却是在事务未提交的状态下，池里拿到的连接带脏状态。

解决思路分两路。代码层面，坚持用try-with-resources或者统一封装close方法，别心存侥幸。运维层面，通过连接池监控观察活跃连接数随时间是否持续上升，如果曲线一直在涨，基本就是泄漏了。

还有一种快速定位法，查询MySQL当前连接和对应来源：

SELECT id, user, host, db, command, time, state FROM information_schema.processlist ORDER BY time DESC;

如果看到大量Sleep状态的连接长时间挂着，十有八九是连接没关闭。这时候可以用show processlist逐步对上应用日志里的执行线程，找出具体泄漏的代码块。

4.2 MySQL 8小时连接失效问题

经典的“Communications link failure”错误，通常发生在系统隔了一段时间没操作之后，再查询突然报错。原因是MySQL服务端有一个wait_timeout参数，默认28800秒（8小时），连接空闲超过这个时间会被服务端主动断开。而连接池里的连接池自己不知道，它认为连接还存在，复用时就拿到一个已失效的连接，直接抛异常。

在PostgreSQL里叫idle_in_transaction_session_timeout，在MySQL里是wait_timeout和interactive_timeout，不同数据库都有类似的空闲超时机制。

解决方案有几个方向：

最正规的做法是配置连接池侧的两个参数：max-lifetime（连接最大存活时间）必须小于数据库的wait_timeout，比如MySQL设8小时，HikariCP的max-lifetime就设30分钟或1小时，这样连接会在空闲超时之前被池子主动回收重建。HikariCP本身也会定期执行连接测试，可以通过connection-test-query配置（MySQL一般是SELECT 1）验证连接是否可用。

另外可以加一个轻量心跳查询，让连接定期活跃。但这不是好方案，相当于用假流量来维持连接，纯粹治标不治本，而且白白消耗数据库资源。

我现在处理这个问题的方式很固定：查数据库参数、确认超时值、把连接池max-lifetime调成它的一半以下，然后重置业务操作时间。视觉上问题消失，根因上也彻底解决。

4.3 “Unknown column 'xxx' in 'field list'”的隐蔽原因

这个报错看起来像SQL写错了列名，但有时候SQL核对一整天都找不出问题。真正坑人的是驼峰命名和下划线命名的自动映射错位。比如实体类字段是orderNo，数据库列名是order_no，如果你用没有映射关系的原生JDBC查询：

SELECT order_no FROM user_order;

然后用rs.getString("orderNo")去取值，就会报未知列的错误。这里的误区是前面我推荐的“用列名取值”，但项目里有人图省事直接用了Java字段名当成结果集列名。

解决办法其实不难：给查询列起别名，让列名和Java字段保持一致，或者统一遵守数据库列名下划线的规范，取值时严格用下划线名称。我最推荐的方案是在SQL里显式写好别名，哪怕数据库列名和字段名不一致，代码也不会被坑：

String sql = "SELECT order_no AS orderNo, user_id AS userId FROM user_order WHERE id = ?";

4.4 排查工具和速查表：少走弯路的捷径

JDBC排查过程中，有几个工具和命令是高频使用的，我整理成速查表：

排查思路建议采用“自底向上”法：先看数据库进程里有没有阻塞，再看连接池监控里连接是否正常，接着看代码里资源有没有泄漏，最后才怀疑SQL本身有问题。很多人一上来就优化SQL，绕了一圈发现根本不是SQL的锅，浪费时间。

另外强烈推荐在项目里接入一个数据源监控。Druid自带监控页面，HikariCP也可以通过Metrics接入Prometheus。有了监控，连接数、活跃线程、SQL执行耗时这些指标都能可视化，出问题时不用靠猜，直接看数据说话。

结尾

JDBC这一整套东西，从连接到事务、从预编译到批处理，每一个点拆出来都不算高深，但组合在一起就是一门实打实的工程学问。我个人经验是，学习JDBC最好的路径不是读文档，而是直接找一个实际业务场景，比如用户订单模块，从建表开始到CRUD、事务、批量导入，整个流程手写一遍，踩一遍坑就全通了。

其中最值得你花时间的两个方向：一个是事务边界管理和连接生命周期控制，这两个是生产事故高发区，出问题定位成本极高；另一个是批量参数优化，rewriteBatchedStatements+ 合适的batchSize带来的性能提升会刷新你对JDBC的认知。

最后再分享一个小技巧：看到框架的SQL日志别直接跳过，把它打印出来的SQL复制到数据库客户端，用EXPLAIN分析一下执行计划。你不需要改动任何业务代码，但能从框架生成的SQL里看出索引命中情况、连接查询方式，很多数据库层面的性能隐患都能在这个环节提前暴露。这个习惯坚持一两年，你的SQL功底和数据库调优能力会远超同行。