JDBC 批处理这个题目我在实际项目里反复踩过坑之后才真正搞明白。很多同学写 JDBC 代码上来就是 for 循环里一条一条 executeUpdate数据量小没感觉一旦上了万级、十万级那速度和数据库压力立刻见真章。Batch Processing 并不是什么高深概念核心就一句话把多条 SQL 攒在一起一次发给数据库执行用网络往返次数的减少来换吞吐量的提升。但真把它用好里面涉及 API 细节、驱动参数、事务边界、异常处理一堆门道不是调个 addBatch 就万事大吉。这篇内容适合正在用 JDBC 连接 MySQL、Oracle 等关系型数据库做数据同步或批量导入的 Java 开发者也适合在用 Flink 或其他框架做数据集成、对 JDBC 连接器批量写入行为感到困惑的同学。我会把整个批处理从原理到实操、从参数调优到问题排查完整过一遍尽量讲清楚每个选择背后的为什么。1. JDBC 批处理到底解决什么问题1.1 从一次批量入库的痛点说起先回忆一个典型场景你有一份 Excel 导出的十万行数据要写进 MySQL 的一张业务表。最朴素的写法是for (Row row : rows) { String sql INSERT INTO t_user(name, age) VALUES( row.getName() , row.getAge() ); statement.executeUpdate(sql); }这一段代码如果真跑起来耗时通常在几分钟甚至更久。问题出在哪里不是 SQL 本身复杂而是每一次 executeUpdate 都是一次完整的网络往返客户端把 SQL 发到数据库服务器服务器解析、优化、执行再返回结果。十万条数据就是十万次网络往返每次哪怕只有 0.5 毫秒的延迟光网络开销就是五十秒再加上 SQL 解析和事务开销整体性能自然惨不忍睹。批处理的思路简单粗暴把这一万条 INSERT 攒一攒一次性发给数据库。假设客户端和数据库在同一内网一次往返 0.3 毫秒攒成每批 1000 条发送十万条数据只需要一百次往返网络开销直接缩到原来的千分之一量级。用生活里的话说逐条插入就像每次只往货车上搬一块砖批处理则是先把砖堆好再整车拉走搬运次数少了效率自然上去。1.2 批处理省的到底是什么很多人以为批处理省的是 SQL 拼接时间其实那点 CPU 消耗微乎其微。真正省下来的大头是三类开销第一是网络往返 RTT。这是最直观的收益减少客户端和数据库之间的交互次数。一次交互不论数据多少固定成本都在那里批处理能让一次交互携带尽可能多的有效数据。第二是 SQL 解析和优化开销。数据库收到一条 SQL要先做词法分析、语法分析、生成执行计划。PreparedStatement 本身可以通过预编译让执行计划复用但批处理在此基础上进一步降低了驱动层和协议层的开销。第三是事务开销。MySQL 默认 autocommit 开启每条 INSERT 独立事务意味着每条都要刷一次事务日志。批处理配合手动事务可以把一批操作合并成一个事务日志刷盘次数从 N 次降为 1 次。明白了这三点你就知道批处理不是“银弹”它的优化空间主要在降低交互频率和降低事务频率。数据量只有几十条时批处理的收益不明显甚至因为攒批逻辑的额外代码而显得多此一举。但是当数据量达到千条以上尤其涉及定时任务、数据迁移、日志入库这类场景批处理几乎是必须的手段。2. 核心 API 拆解与执行流程2.1 三个关键方法addBatch、executeBatch、clearBatchJDBC 批处理的标准用法是这样的PreparedStatement ps conn.prepareStatement(INSERT INTO t_user(name, age) VALUES(?, ?)); for (int i 0; i 10000; i) { ps.setString(1, user_ i); ps.setInt(2, 20 (i % 50)); ps.addBatch(); if (i % 1000 999) { ps.executeBatch(); ps.clearBatch(); } } ps.executeBatch();addBatch 做的事情是把当前绑定的参数记录到驱动内部的一个缓冲区注意它只是“记下来”并没有真正发往数据库。executeBatch 才是一次性把缓冲区里的 SQL 全部发给数据库执行。clearBatch 则是清空缓冲区防止重复执行或内存积压。这里有一个非常关键的顺序问题先 addBatch 再 executeBatch执行完一批之后必须 clearBatch。很多新手漏掉 clearBatch导致下一轮 addBatch 时旧的参数还在缓冲区里最终 executeBatch 把历史数据又执行一遍造成重复插入。我见过因为这个原因跑出的数据翻倍事故排查起来还特别隐蔽因为日志里看不出任何异常。2.2 executeBatch 返回值的含义executeBatch 的返回值是一个 int[]每个元素对应批里一条 SQL 的受影响行数。这个数组在你执行 INSERT、UPDATE、DELETE 时通常是有实际意义的比如插入 1000 条数组里每个元素基本都是 1。但有一个很容易踩的坑并不是所有数据库驱动都会准确返回每条语句的影响行数。MySQL 驱动在某些情况下——比如开启了 rewriteBatchedStatements 参数后——返回的数组元素可能是负数Statement.SUCCESS_NO_INFO -2表示执行成功但行数未知。这是正常的不代表出错。判断批量执行是否成功的标准是“是否抛异常”而不是“返回数组是否全为 1”。去逐条校验返回值在老驱动上反而可能引发额外查询开销得不偿失。2.3 攒批缓冲区与内存问题addBatch 是把参数保存在客户端内存里的所以批大小直接决定内存占用。一个极端情况如果有人循环一万条数据全部 addBatch 不执行那么 PreparedStatement 对象中持有的参数数组就会越来越大GC 压力随之上升极端情况下还可能 OOM。我通常建议单批大小控制在 500 到 2000 条之间具体取决于单条数据的字段长度。如果一条记录有几十个字段单条 SQL 特别长那么建议往小了取500 甚至 200 都行如果单条 SQL 很短2000 到 5000 也可以尝试。没有通用标准需要结合网络环境和数据库性能实测确定。后文我会专门讲一个简单的实测方法。3. Statement 批处理与 PreparedStatement 批处理的差异3.1 两种 API 的编码差异Statement 批处理是把完整 SQL 字符串追加进批缓冲区Statement stmt conn.createStatement(); for (int i 0; i 1000; i) { String sql INSERT INTO t_user(name, age) VALUES(user_ i , (20 i % 50) ); stmt.addBatch(sql); } stmt.executeBatch();PreparedStatement 批处理则是绑定参数之后 addBatchPreparedStatement ps conn.prepareStatement(INSERT INTO t_user(name, age) VALUES(?, ?)); for (int i 0; i 1000; i) { ps.setString(1, user_ i); ps.setInt(2, 20 i % 50); ps.addBatch(); } ps.executeBatch();两种写法都能实现批处理但深层差异很大。Statement 的问题在于每次 addBatch 都要拼接 SQL 字符串同样一条 INSERT 因为参数不同SQL 文本完全不同数据库每次都要重新做语法解析和生成执行计划。PreparedStatement 的 SQL 结构固定只有参数变化驱动侧可以做更激进的优化数据库侧也能复用预处理语句的执行计划。3.2 注入安全与性能的双重考量从安全性来看Statement 拼接 SQL 会引入 SQL 注入风险尤其当参数来自外部输入时这就是一个明显的漏洞。PreparedStatement 通过参数占位符将数据与 SQL 结构分离从机制上规避了注入问题。这一点在批处理场景同样成立有人在批处理时图省事用 Statement 拼字符串一旦某个字段值里包含单引号、分号等特殊字符轻则语法错误重则被注入攻击。从性能来看在 MySQL 5.7 以后、MySQL Connector/J 8.x 的环境下两种方式的批处理差距比很多人想象中更大。原因在于 MySQL 驱动对 PreparedStatement 的批处理有一个专门的优化路径需要配合 rewriteBatchedStatements 参数开启这个参数 Statement 批处理是用不上的。所以我的建议非常明确批处理一律用 PreparedStatement没有任何理由用 Statement。3.3 自增主键获取与批处理的冲突业务中常见的需求是插入数据后拿到自增主键比如插入订单后需要回填订单号。单个插入时可以这样做PreparedStatement ps conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); ps.executeUpdate(); ResultSet rs ps.getGeneratedKeys();但批处理时这个玩法会变得很麻烦。MySQL Connector/J 在批处理模式下getGeneratedKeys 通常只能拿到最后一条插入产生的自增主键或者干脆返回空 ResultSet这和驱动的实现有关不同版本行为还不一致。如果你确实需要在批量插入后获得每个主键有三个可选方案一是在插入前通过应用层生成主键比如用雪花算法生成 ID 后再走批处理这是最干净的做法二是分批插入每批规模控制在驱动能正确返回的范围内再逐批获取主键三是插入后用唯一业务键反查主键但这多一次查询只适合数据量不大的场景。我个人强烈推荐方案一应用层生成主键虽然牺牲了数据库自增的便利但在批处理场景下它解决的不只是主键获取问题还能顺便获得全局唯一 ID为后续分布式架构铺路。4. MySQL 驱动参数调优性能差距的关键所在4.1 rewriteBatchedStatements 参数这个参数是 JDBC 批处理性能的分水岭。MySQL Connector/J 默认不对 INSERT 批处理做重写也就是说你 addBatch 了一千条 INSERT驱动仍然可能一条一条发给数据库。这样做的好处是兼容性好坏处是性能完全没有提升。打开方式是在 JDBC URL 上追加参数jdbc:mysql://127.0.0.1:3306/test?rewriteBatchedStatementstrue开启后驱动会把一批 INSERT 重写成多值插入的形式比如INSERT INTO t_user(name, age) VALUES (a, 1), (b, 2), (c, 3), ...这样一次网络往返携带的 SQL 里包含多组 VALUES数据库解析一条语句就完成多行插入性能和批处理意图完全匹配。实测同一批一万条数据在不开这个参数时耗时可能接近 8 到 10 秒开启后能降到 1 秒以内量级提升非常明显。需要注意两点。第一rewriteBatchedStatements 只对 INSERT 生效对 UPDATE、DELETE 批处理无效因为 MySQL 不支持一条 UPDATE 同时改多行不同条件。第二重写后的 SQL 会丢失原本的 RETURN_GENERATED_KEYS 能力这进一步印证了我刚才说的自增主键方案。4.2 useServerPrepStmts 与 cachePrepStmts 的配合除了 rewriteBatchedStatements还有两个参数经常被一起讨论useServerPrepStmts 和 cachePrepStmts。useServerPrepStmtstrue cachePrepStmtstrue prepStmtCacheSize256 prepStmtCacheSqlLimit2048useServerPrepStmts 的作用是让 PreparedStatement 的预编译发生在服务器端而不是客户端模拟。默认情况下 MySQL Connector/J 在客户端拼接参数、不做真正的服务端预处理开启后会将 SQL 发送给服务器预编译之后执行只需要传参数。这样能降低服务端解析开销但要注意只有同一个 PreparedStatement 对象被反复复用时才能真正体现预编译的价值如果每次都新建、用完就弃服务端预编译反而增加了额外开销。cachePrepStmts 则是把预编译好的语句缓存起来配合 prepStmtCacheSize 控制缓存数量。这套组合在连接池场景下效果突出因为连接池会复用物理连接缓存能跨业务方法生效。对于短连接连接 MySQL 的场景这些参数的作用会打折扣。还有一个细节值得注意开启 useServerPrepStmts 后PreparedStatement 批处理在某些版本下可能反而变慢原因是服务端预处理语句的批量执行走了一条不同的协议路径。如果你在做完参数调优后发现性能不升反降可以尝试关闭 useServerPrepStmts、保留 rewriteBatchedStatements很多场景下这个组合反而最快。4.3 合理的批处理大小实测方法批大小不是拍脑袋定的我建议用「阶梯压测」的方法来定。具体做法是准备一千、五千、一万、两万条实际业务数据分别用 100、500、1000、2000、5000 的批大小去跑记录耗时和数据库 CPU 使用率。选型的两个原则同等数据量下耗时最低数据库 CPU 没有长时间飙高。批大小过大比如一次 5 万条虽然网络往返少了但数据库需要解析一条超长 SQL锁竞争和事务日志压力都会上升对并发写入能力反而是伤害。批大小过小比如 50 条一批虽然每条 SQL 很短但网络往返次数还是多吞吐上不去。实际项目里我通常从 500 开始压测数据量大且字段少时可以逐步上调到 2000超过 5000 的情况很少见。对于 Flink 等框架的 JDBC 连接器批处理大小的配置本质也是这个问题连接器底层一定调用了 JDBC 的 addBatch 和 executeBatchbatchSize 参数控制的就是攒多少条执行一次。所以理解了 JDBC 层面的原理再看 Flink 连接器配置就不会觉得那是黑盒。5. 事务边界与批处理的配合5.1 手动事务是批处理的前提JDBC 默认 autocommit 为 true意味着每次 executeBatch 之后数据立即被提交。这会导致一个很容易被忽视的问题如果数据量大、执行时间长中途发生异常已经提交的批次无法回滚只能重跑剩余部分非常难维护。正确做法是把 autocommit 关掉手动控制事务边界conn.setAutoCommit(false); try { // 循环 addBatch executeBatch conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); }这样整批数据要么全部提交成功要么全部回滚保证了原子性。数据迁移、ETL 这类场景尤其依赖这个特性否则失败后留下的半截数据会是你排查问题的噩梦。5.2 事务粒度与批量提交的折中有人会问既然手动事务这么好那我把十万条数据全放在一个事务里执行行不行答案是不能至少不该轻易这么做。一个事务包含的写入量越大事务持锁时间越长数据库的 undo 日志、redo 日志压力越大对其他并发事务的阻塞也越严重。在 MySQL InnoDB 下一个超长事务提交时还可能出现 binlog 写入量暴涨、复制延迟飙升的问题。比较稳妥的做法是分批但共享一个更大的任务级补偿机制。比如一万条数据分成十批每批 1000 条在各自事务中提交但整体任务记录一个批次状态表。某批失败时只重跑这一批而不是整体回滚。这就是典型的“批内事务 批间断点续传”思路在 Flink 的 JDBC sink 里这个思路演化为 checkpoint 配合两阶段提交本质也是控制事务粒度、保证 Exactly-Once 语义。6. 完整实操一个可落地的批量入库工具类6.1 依赖与环境准备我用 MySQL 8.0 为例JDBC 驱动选择 mysql-connector-java 8.0.33。Maven 依赖如下dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency连接 URL 使用连接池参数按前面调优后的配置jdbc:mysql://127.0.0.1:3306/test?useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrueuseServerPrepStmtstruecachePrepStmtstrueprepStmtCacheSize256prepStmtCacheSqlLimit20486.2 批量写入的标准模板代码下面是一个完整可运行的批量入库方法兼顾了性能与事务安全public class BatchInsertDemo { public static void batchInsert(ListUser userList) throws SQLException { String url jdbc:mysql://127.0.0.1:3306/test?useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrueuseServerPrepStmtstruecachePrepStmtstrueprepStmtCacheSize256prepStmtCacheSqlLimit2048; String sql INSERT INTO t_user(name, age, created_at) VALUES(?, ?, NOW()); int batchSize 1000; try (Connection conn DriverManager.getConnection(url, root, pass); PreparedStatement ps conn.prepareStatement(sql)) { conn.setAutoCommit(false); int count 0; for (User u : userList) { ps.setString(1, u.getName()); ps.setInt(2, u.getAge()); ps.addBatch(); count; if (count % batchSize 0) { ps.executeBatch(); ps.clearBatch(); conn.commit(); } } // 处理尾数 ps.executeBatch(); conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } } static class User { String name; int age; // getter/setter 略 } }这段代码有几个值得注意的细节。try-with-resources 确保连接和语句对象一定被关闭避免连接泄漏。executeBatch 前先 clearBatch防止残留参数。每满 batchSize 就提交一次而不是全部跑完才提交这个设计就是为了避免过大的事务粒度。尾数处理要特别留意如果总条数正好被 batchSize 整除最后一次循环后没有执行 executeBatch 的批次所以循环结束后的 executeBatch 是必须的。6.3 实测对比数据我在本地环境MySQL 8.0同机部署万条数据跑过一次简单对比结果如下方式耗时说明逐条 executeUpdateautocommittrue约 9000 ms每条独立事务网络往返PreparedStatement 批处理未开 rewrite约 2600 ms批处理生效但未重写 SQLPreparedStatement 批处理开 rewrite约 680 ms多值插入收益最大开 rewrite 手动事务 batch1000约 520 ms事务开销进一步降低同一台机器、同一份数据从 9 秒优化到 0.5 秒差距接近 18 倍。注意这个数字不是绝对的和字段数、索引数、服务器配置都有关系但趋势是一致的。如果表上索引特别多批量插入的耗时会被索引维护拖慢这时候可以考虑先禁用非必要索引、导入完成后再创建。7. 常见问题与排查实录7.1 批处理执行时报 CommunicationsException 或连接中断现象大批量 executeBatch 时抛 com.mysql.cj.jdbc.exceptions.CommunicationsException或者提示 Connection is not available请求被中止。这个问题的常见原因有两个。一是 MySQL 的 max_allowed_packet 参数设置太小。rewriteBatchedStatements 开启后一条重写后的 INSERT 可能包含几千组 VALUESSQL 总长度会非常大如果超过 max_allowed_packet连接会被直接断开。解决方式是调大该参数比如SET GLOBAL max_allowed_packet 64 * 1024 * 1024;注意这个参数同时要检查客户端和服务端Connector/J 自身也有 maxAllowedPacket 参数与之呼应。第二个原因是批大小过大导致单次传输数据量超限。如果你不想全局调大 max_allowed_packet那就调小批大小几百条一批SQL 总长度自然降下来。我在实践中更倾向后者因为全局参数过大会给恶意超长 SQL 留下利用空间。7.2 executeBatch 返回 0 影响行数执行成功但 int[] 全是 0或者包含 SUCCESS_NO_INFO。这种情况在 MySQL 开启 rewriteBatchedStatements 后尤其常见驱动重写 SQL 后无法精确统计每行的影响行数于是用 0 或 -2 占位。这本身不是错误。判断成功与否应该看是否抛 SQLException而不是检查影响行数。如果你非要用影响行数做后续判断建议在单独事务里 count 一下数据量别依赖 executeBatch 的返回值。7.3 批处理中途失败如何定位是哪条数据JDBC 批处理失败时异常信息通常只会告诉你 SQL 是哪一个 batch 的某条语句不会精确到参数组合。定位的方式是把批大小缩小二分法排查或者在 addBatch 时维护一个自增序号一旦 executeBatch 失败通过异常信息里的 batch 序号范围缩小到某一批再在该批中逐条尝试定位。以我自己处理过的案例为例一次导入时某条数据包含一个超长字符串字段超过了列定义长度整批执行失败。因为异常信息只显示“Data too long for column remark”没有指明是哪一行我用了两步先按 500 条一批重放失败时不断二分缩小范围最终在 4 次执行内定位到具体数据。如果数据量大这个排查法比肉眼筛查靠谱得多。7.4 Flink JDBC 连接器批量写入异常怎么查很多人在 Flink 任务中做维表 Join 后写入 MySQL遇到连接器报错时习惯先怀疑框架其实底层仍是 JDBC 批处理逻辑。常见异常有这几类第一DeadlineReachedException通常出现在连接超时检查 Flink 的 JdbcExecutionOptions 中 batchSize 和 batchIntervalMs 配置。如果 batchSize 设得过大而单条数据又很宽一次 executeBatch 的数据量可能把数据库连接窗口撑爆。调小 batchSize 往往直接见效。第二MySQL 锁等待超时批量写入和业务上的长查询互相锁表。连接器的批处理事务粒度较大时锁持有时间更长表现为 Lock wait timeout exceeded。解决方案是调小 Flink 连接器的 batchSize减少单事务的锁范围或者在 SQL 侧优化慢查询缩短锁持有时间。第三Exactly-Once 模式下 checkpoint 失败往往是 JDBC 连接不稳定或事务未正确提交。连接器内部使用了 XA 或事务钩子实现两阶段提交失败时先检查数据库是否支持分布式事务再看 checkpoint 超时时间是否够用。看 Flink 连接器的日志时注意区分「连接器内部抛出的异常」和「数据库端返回的异常」。数据库端异常往往带有 SQLState 和 ErrorCode比如 1213死锁、1205锁超时这些信息比框架堆栈直接得多直接在 MySQL 错误码对照表里搜索即可。7.5 问题速查表现象可能原因解决方向批处理超慢无提升未开启 rewriteBatchedStatementsURL 增加该参数并确认生效executeBatch 连接中断max_allowed_packet 过小调大参数或调小批大小返回值为 0 或负值驱动重写后无法统计行数不以返回值判断成功看是否抛异常重复插入数据漏了 clearBatch每批 executeBatch 后立即 clearBatch大批量事务提交慢单事务太大undo/redo 压力高控制事务粒度设 batchSizeFlink 写入锁超时批大小过大或慢查询锁冲突调小 batchSize优化 SQL自增主键获取为空批处理与 getGeneratedKeys 不兼容应用层预生成主键排查时有一个总原则先确定是不是 JDBC 驱动层的问题再确定是不是数据库参数的问题最后才是业务数据的问题。驱动版本不同批处理行为差异很大升级驱动前后行为变化也是常见排查线索。8. 一些个人体会与扩展思路批处理优化到后面瓶颈往往不在 JDBC 本身而在数据库的写入能力。单条 INSERT 改成多值 INSERT 之后数据库的解析时间、日志写入时间、索引维护时间才是真正的限制。拿我最近在做的实时数据同步任务来说从消息队列消费数据后写入 MySQL总共涉及十几个表的写入逻辑。最初每个表单独写一套批处理代码后来抽象成通用的基于 PreparedStatement 的批量写入工具连接参数、批大小、事务策略全部可配置代码量缩了一半问题定位也简单了。如果后续你想在这个基础上继续深挖考虑两个方向一是连接池的配置与批处理参数的配合Druid、HikariCP 对 PreparedStatement 缓存的策略不同实测差异明显二是在数据量超过单机数据库写入上限时引入分库分表或用分布式数据库替代单体 MySQL。批处理思想不变但实现的中间件变多了。最后分享一个我踩过几次坑后的固定经验每次写完批处理代码先在测试环境用真实数据量跑一遍同时开启数据库慢查询日志观察实际执行情况。不要只盯着耗时数字也要看数据库的 QPS、锁等待和日志增速。批处理优化是一场和数据库的协同作战单看客户端代码永远看不到全貌。