企业官网建设流程全解析

前阵子帮同事排查一个报表导出的性能问题，一万条数据逐条执行 update，跑完要七八分钟，中途还经常超时。改成批量执行之后，同样的数据量四十多秒跑完。改动本身不复杂，但“JDBC 执行多条语句”这件事，实际项目里远不止一种写法，每种写法的性能边界、事务表现、坑点也完全不同。这篇文章我把自己用过的几种方式都整理一下，从 PreparedStatement 批处理到一次 execute 多条 SQL，再到 CallableStatement 调用存储过程，适合刚接触 JDBC 的开发者，也适合正在做老代码性能改造的同行参考。

1. 先搞清楚：JDBC 里“执行多条语句”到底有几种形态

1.1 一个常见的误区：多条语句不等于多次循环执行

很多人一听“执行多条语句”，第一反应就是写个 for 循环，反复调用statement.executeUpdate()。功能上确实能完成，但代价是被忽略的：每执行一条 SQL，客户端和数据库之间就完成一次完整的网络往返，语句解析、权限检查、事务日志这些开销全部重复计算。假设你有一万条 insert，逐条执行就是一万次网络往返，哪怕每条只有几毫秒，累加起来就是几十秒到几分钟的量级。

要命的是，这种写法还会把事务边界弄得很模糊。默认 autocommit=true 的情况下，每条 SQL 都是独立事务，一旦跑到一半业务逻辑抛异常，已经执行的语句全部永久生效，根本无法回滚。后面我会讲到，正确处理多条语句的时候，事务要么整体提交，要么整体回滚，这里是最容易被人忽略的第一道坎。

所以，把“执行多条语句”真正拆开，我们要讨论的其实是三个能力：把多条 SQL 打包成一个批处理交给数据库；在一个网络请求里发送多条用分号分隔的语句；把多条 SQL 预先写在数据库端，通过一个调用入口执行。

1.2 三种形态的适用场景速查

绝大多数日常业务场景，第一优先级都应该是批处理。只有在写一次性脚本、或者业务逻辑确实强依赖数据库端的循环处理时，才轮到后面两种方式。接下来我逐个展开，把实现细节和踩过的坑都说清楚。

2. 最常用方案：PreparedStatement 批处理拆解

2.1 十秒钟理解 addBatch 和 executeBatch 的运作逻辑

想想你点外卖的场景：一个菜一个菜地下单，和把一购物车的东西一次性结算，本质区别在于后者把多次交互合并成了一次。addBatch()干的就是“把 SQL 加入购物车”，executeBatch()才真正去“结算”。对数据库来说，一次收到一批结构相同的数据，绝大部分解析工作可以复用，执行计划也只需要生成一次，这就是批处理性能好的根本原因。

顺手写一段最基础的批量插入代码，你可以直接跑一下感受效果：

String sql = "INSERT INTO tb_order_detail(order_id, sku_id, quantity, price) VALUES (?, ?, ?, ?)"; try (Connection conn = dataSource.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { conn.setAutoCommit(false); for (OrderDetail item : orderDetailList) { pstmt.setLong(1, item.getOrderId()); pstmt.setLong(2, item.getSkuId()); pstmt.setInt(3, item.getQuantity()); pstmt.setBigDecimal(4, item.getPrice()); pstmt.addBatch(); // 每500条提交一次，避免单次批次体量过大 if (item.getIndex() % 500 == 0) { pstmt.executeBatch(); } } pstmt.executeBatch(); // 提交剩余不足500条的那部分 conn.commit(); }

注意几个要点。setAutoCommit(false)必须放在批处理前面，否则很多驱动会在每次executeBatch()时自动提交。分批是经验值，500 到 1000 条一批比较均衡，批次太大会吃掉较多客户端内存，批次太小又体现不出批量优势。最后别忘了再执行一次executeBatch()，因为循环里的整除条件往往覆盖不到最后一批数据。

2.2 MySQL 场景下必须知道的 rewriteBatchedStatements 参数

这里要展开一个容易被忽略、但影响巨大的参数：rewriteBatchedStatements。这个参数默认是 false。在 MySQL JDBC 驱动里，如果不开它，驱动收到 500 条 insert 只会笨拙地逐条发给服务端，性能提升非常有限。设置成 true 之后，驱动会把批量 insert 改写成一条多 VALUES 的语法，比如一条 SQL 里带 500 组括号参数，发送效率完全不同。

连接串配置示例如下：

jdbc:mysql://localhost:3306/yourdb?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true

第一次看到这个参数时，可以做个简单测算：关闭时批量插入 1 万条耗时 4.7 秒，开启后 0.9 秒，差距非常直观。PostgreSQL 驱动是原生支持批处理的，不需要类似参数；这条主要针对 MySQL。SQL Server 的驱动对批处理的支持也比较成熟，但要注意某些老版本对 insert 和 update 混合批的处理策略不同，需要实际测试确认。

2.3 一个能直接抄作业的批量更新代码模板

批量 insert 的模板大家写得多，但批量 update 的写法很多人反而生疏。同样用addBatch()，只是占位符对应的字段不同，这里放一个我项目里常用的更新模板，包含更新行数的检查和异常回滚：

String sql = "UPDATE tb_order SET status = ?, finish_time = ? WHERE order_id = ?"; try (Connection conn = dataSource.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { conn.setAutoCommit(false); for (Order order : pendingOrders) { pstmt.setInt(1, order.getStatus()); pstmt.setTimestamp(2, order.getFinishTime()); pstmt.setLong(3, order.getOrderId()); pstmt.addBatch(); } int[] results = pstmt.executeBatch(); conn.commit(); for (int i = 0; i < results.length; i++) { // result值取决于驱动实现，可能为更新行数，也可能是-2(SUCCESS_NO_INFO) System.out.println("第 " + (i + 1) + " 条影响行数： " + results[i]); } } catch (BatchUpdateException e) { conn.rollback(); int[] updateCounts = e.getUpdateCounts(); log.error("批处理在第 {} 条之后失败", updateCounts.length); }

下面专门说一说这段代码里最容易踩的坑：executeBatch()返回的 int 数组是什么意思。

2.4 关于 executeBatch 返回值，一个容易误解的细节

executeBatch()返回一个int[]，很多新手以为数组里的每个值就是每条 SQL 影响的行数。这个想法只对了一半。JDBC 规范里允许驱动返回Statement.SUCCESS_NO_INFO，也就是 -2，表示“执行成功但没有行数信息”。MySQL 驱动在rewriteBatchedStatements=true时，多个 insert 被改写成一条多 VALUES 语句后，就无法再精确统计每一条的影响行数，这时返回的往往是 -2，甚至数组里只有个别元素有值。

如果你依赖这个返回值做业务判断，比如“更新了多少条”，最稳妥的办法是不看数组细节，改成通过后续的查询或者累加逻辑来核对结果。否则你会发现同样的代码在 MySQL 上返回 -2，在 PostgreSQL 上正常返回行数，排查半天还以为程序出问题了。这个差异属于驱动行为，不是代码 bug。

还要注意一个细节：不要往批处理里灌入结构差异很大的 SQL。PreparedStatement的批处理设计目标是同构 SQL，如果你在同一个批里一会儿 insert、一会儿 delete、一会儿 update，不同数据库的驱动表现会很不一样，有的直接抛异常，有的默默提交了但性能极差。不同结构的语句拆分到不同的批处理里，才是正确做法。

3. 另一种思路：一次 execute() 发送多条分号语句

3.1 MySQL 的 allowMultiQueries 参数怎么开

有些场景确实想用一条语句搞定多条 SQL，比如初始化脚本、临时数据修补。MySQL 默认不允许在一条execute()里包含多条用分号分隔的语句，需要显式在连接串里打开开关：

jdbc:mysql://localhost:3306/yourdb?allowMultiQueries=true

开启之后，就可以这样写：

String multiSql = "DELETE FROM tb_staging; INSERT INTO tb_staging SELECT * FROM tb_source; UPDATE tb_flag SET processed = 1;"; try (Statement stmt = connection.createStatement()) { boolean hasResultSet = stmt.execute(multiSql); // 首次调用返回 true 表示第一条语句是查询；如果是 update/delete，返回 false }

这里必须提醒一点：allowMultiQueries不是让你在业务代码里把多个 insert 拼在一起追求性能的。你以为减少了网络往返，实际上它把 SQL 注入的入口面积放大了好几倍——字符串拼接的内容越多，被注入的风险就越高。在没有做充分参数化的情况下，千万不要把用户输入直接拼进这种语句里。

3.2 多条语句一次发送的边界条件和雷区

用execute()发送多条语句，并不是所有数据库都支持同样玩法。MySQL 需要上面的开关，默认是关掉的；PostgreSQL 的 JDBC 驱动默认不支持这种方式，官方推荐用批处理；Oracle 则可以通过匿名 PL/SQL 块把多条语句包在一个BEGIN...END;里执行。我实际项目中用这种方式，最常见的场景是跑一次性脚本，跑完就丢弃，没有人会把它放进高频业务路径。

另一个实际麻烦是报错定位。多条语句一起发给数据库，如果第 9 条语句语法有问题，MySQL 的错误信息往往只提示“语法错误”，不会精准告诉你错在哪一段。配合日志排查时，只能靠把语句逐条拆分来定位。所以在多语句执行前，我习惯先写一个断言，把构建好的 SQL 完整打出来，肉眼确认没问题再执行。生产环境下，这个方案的可维护性属实一般，仅适合工具型代码。

还要强调一个事务层面的坑：即使你把多条语句放在一次execute()里，也不代表它们自动在同一个事务中。是否整体提交，依然取决于连接当前的autocommit和事务提交时机。也就是说，这个方案减少了网络交互次数，但并没有带来额外的原子性保证。

4. 存储过程与 CallableStatement：多条语句的“打包执行”终极形态

4.1 CallableStatement 基本写法：以 MySQL 存储过程为例

如果你需要在数据库端完成循环判断、多条 SQL 操作后再返回结果，JDBC 的批处理和allowMultiQueries都不太够用。这个场景属于存储过程的强项：所有 SQL 都在数据库内部执行，Java 端只需要传入参数、获得结果。一个典型的调用示例：

// 存储过程定义：根据订单ID批量更新状态，并返回影响条数 // CREATE PROCEDURE proc_batch_update_order(IN orderId BIGINT, OUT affected INT) // BEGIN // UPDATE tb_order SET status = 2 WHERE order_id = orderId; // SET affected = ROW_COUNT(); // END; String callSql = "{call proc_batch_update_order(?, ?)}"; try (CallableStatement cstmt = connection.prepareCall(callSql)) { cstmt.setLong(1, 10086L); cstmt.registerOutParameter(2, Types.INTEGER); cstmt.execute(); int affected = cstmt.getInt(2); System.out.println("受影响行数：" + affected); }

从这个例子能明显看出差异：Java 代码 responsibilities 降到了只负责传参和拿结果，真正的多条 SQL 复杂性全部沉淀在存储过程内部。网络往返次数和 SQL 解析次数都被压到了最低，这就是它在某些批处理场景性能突出的原因。

4.2 存储过程方案的真实权衡

先说结论：能用批处理解决的就不要上存储过程，但有些老系统确实已经用存储过程承载了大批复杂逻辑，硬改成 Java 端批处理反而引入风险。

存储过程的优点很明显。最直观的是性能稳定：存储过程在创建时就完成了语法解析和编译，后续调用直接利用缓存，不需要每次重新解析。多条语句之间的中间结果可以直接用临时表保留，省去客户端和服务端之间的反复数据搬运。很多报表类、结算类系统里，复杂统计用存储过程跑，性能比在 Java 端逐条查询再计算简单粗暴得多。

缺点也不容回避。代码维护需要同时掌握两门语言，Git 管理存储过程版本天然不如管理 Java 代码方便。数据库从 MySQL 迁移到 PostgreSQL 时，存储过程的改写成本往往比改 Java 代码还高。更微妙的是权限管控：为了让存储过程正常运行，账号可能需要较高的数据库权限，这本身就是安全隐患。

要特别提醒一类现象：很多流处理框架或者批处理任务接入 JDBC 时，报出一堆 “Jdbc execute error” 或连接异常，排查到最后，往往不是框架的 bug，而是批处理参数没配对、连接池允许的最大活跃连接数不够、数据库 wait_timeout 太短这三个原因叠加的结果。存储过程方案也不能免疫此类问题，因为连接层面上的坑是通用的。

5. 实操踩坑实录：常见问题与排查清单

5.1 executeBatch 部分成功时，如何判断哪些数据失败了

有业务逻辑要求“要么全部成功，要么全部回滚”，这个在setAutoCommit(false)+commit()的组合下是好做到的。但还有一种需求是“尽量多的数据入库，失败的部分单独记录”——这个时候不能无脑回滚，而是需要精确定位失败点。

BatchUpdateException.getUpdateCounts()返回的数组能反映每一批语句的执行情况。数组长度如果小于你提交的批次大小，说明执行到某个位置中断了。更实际的方案是给每条数据加一个业务唯一标识，比如order_id，失败时通过日志落库。我用过的一种可靠做法：批处理外层包 try-catch，出错后用失败数据的分页条件重新查询一遍，算出哪些没进库，再走单条补偿流程。虽然多写几行代码，但生产环境可追溯性比只看异常原因有用得多。

5.2 MySQL 批处理返回 -2 是失败吗

回到前面提过的 -2 问题，这里给一个简洁结论：SUCCESS_NO_INFO表示成功但没有行数统计信息。如果你看到批量 update 的结果全是 -2，不要慌张，先确认rewriteBatchedStatements是否开启。开启 MySQL 的批处理改写后，驱动为了保证性能确实会放弃逐条统计。反之，如果rewriteBatchedStatements=false，部分版本的驱动会老老实实返回每条语句实际影响行数，但性能差那么多，为了行数统计牺牲性能不划算。

5.3 空批次调用 executeBatch 会怎样

一个很容易忽视的细节：如果addBatch()一条都没调用就直接executeBatch()，MySQL 驱动会直接抛异常。这是驱动层面的保护机制，避免把空内容送到服务端。所以代码里一定要加保护，尤其是循环出来的集合可能为空时：

if (batchCount > 0) { pstmt.executeBatch(); }

5.4 连接池参数和 JDBC 超时配置

即便批处理这块代码没问题，运行一段时间后也可能突然报连接错误。排查时优先看三处：连接池maximumPoolSize是否够大、connectionTimeout是否过短、数据库wait_timeout有没有把空闲连接回收掉。很多“批量跑了一半就断连”的问题，根源不是 JDBC 代码，而是连接被数据库主动断掉后连接池又给了一个失效连接。

调试手段上，打开 MySQL 的通用日志可以直观看到客户端实际发过来的 SQL 形态，能判断批处理到底有没有被 rewrite 成多 VALUES 语法。JDBC 驱动层面也可以用日志追踪连接状态：MySQL 驱动通过logger=com.mysql.cj.log.Slf4JLogger开启，PostgreSQL 驱动则靠loggerLevel=DEBUG控制。这些日志输出会比较多，建议只在排查问题时临时开启。

5.5 一段可复用的批处理性能测试思路

想测量自己写的批处理到底快在哪，最直接的办法是控制变量做对比测试。同一张表、同一批 5000 条数据，分别用三种方式执行：逐条执行、不开rewriteBatchedStatements的批处理、开启rewriteBatchedStatements的批处理。记录耗时后，你会发现差距基本在数量级。这类测试记得把第一次执行的结果丢弃，因为表结构和 SQL 在数据库端的缓存预热会影响第二次、第三次的耗时，连跑五次取中位数更能说明问题。

我自己的经验里，批处理和存储过程从来不是一个二选一的命题，更多时候是按场景组合：日常写入用批处理，复杂计算或事务链路特别长的场景才让存储过程兜底。最后再分享一个小技巧：批处理里拼 SQL 时，尽量保持列顺序一致，占位符号顺序固定，这样不仅能减少 SQL 层面的解析差异，还能让你在排查SQLException时，一眼看出是哪一列的数据出了问题。代码可以写得很快，但要想线上跑得稳，这些细节值得花时间打磨。