做数据导入这类活儿，最让人抓狂的往往不是业务逻辑，而是那一句句INSERT。我之前在做一个外部数据日粒度入库的任务，每天要写入十万级的数据，起初用最朴素的JDBC逐条插入，整个跑批四十分钟起步，还经常因为超时接到运维电话。后来把代码切成JDBC批处理（Batch Processing），同一个任务缩短到三分钟左右。这篇文章就把批处理这件事讲透：它到底解决了什么问题、正确用法是什么、为什么有人写了批处理提速却不明显，以及我实操中踩过哪些坑。无论你是刚学JDBC的新手，还是正在优化批量导入的老手，希望都能从里面拿走点能直接落地的经验。
1. 批量插入慢在哪儿：一次网络往返吃掉的时间
1.1 JDBC执行单条SQL的完整链路
很多同学对“慢”的认知停留在“数据库执行慢”上，其实一条INSERT从客户端发出到服务端返回，要经历的环节远比“执行”两个字复杂得多。我习惯把它拆成六段：
- 代码层：创建PreparedStatement，绑定参数，拼装SQL。
- 驱动层：JDBC驱动把参数类型编码、序列化成数据库能解析的协议格式。
- 网络传输：客户端和服务端之间的一次往返，物理距离越远，这里越痛。
- 服务端解析：数据库收到SQL后做语法解析、权限校验、生成执行计划。
- 真正执行：锁行、改索引、写binlog/redo日志。
- 结果返回：把影响行数和结果集送回客户端。
注意，这里说的是“一次”完整链路。如果你插入1万条，这条链路就要完整走1万次。网络往返和解析的开销，在数据量小的时候完全无感，到了万级、十万级就成了顶在最前面的瓶颈。特别是跨机房、连云上数据库的场景，单次往返0.2ms到1ms是常态，1万次就是好几秒到十几秒，还没算数据库真正干活的时间。
这个链路很好理解，就像去柜台办事，办一笔业务要排一次队、递一次材料、等一次审核。JDBC批处理的思路很简单：不让你1万次反复排队，而是把材料攒成一摞，一次性递进去。
1.2 1万条逐条插入的性能账本
我习惯把“慢”量化成账本。假设平均一条INSERT从发起到返回需要5ms，逐条插1万条需要的总时间是：
10000 × 5ms = 50000ms，也就是50秒。
这里的5ms已经是理想值，真实场景往往更高。而且有个容易被忽略的事实：单条INSERT执行时，服务端每一条都要重走一遍SQL解析和优化，这部分CPU开销很贵。也就是说，逐条插入不仅是网络在等，数据库侧的解析引擎也在反复空转。
换到批处理视角，如果我们把1万条语句攒成10批，每批1000条，发送到服务端后由优化器统一处理，网络往返次数从1万次降到10次上下，解析次数也大幅下降。在开启合并重写的前提下，同样的1万条插入可以压到1秒左右。
1.3 批处理为什么快：牺牲实时性换吞吐
JDBC批处理的核心，不是把SQL“压缩”成什么神奇格式，而是三个字：攒批。攒批的本质是牺牲掉“每条数据立即生效”的实时性，换取更高的整体吞吐量。
代价也很明确：同一批数据内部，如果某一条失败了，前面已经执行成功的行不会自动跟着撤销，除非你把这些批次包在一个事务里统一提交或统一回滚。这个特性决定了批处理适合的场景——大量数据的导入、清洗后的落库、日志归档，而不是高实时性的交易链路。
理解这一点很重要，因为后面的代码写法、事务配置、批次大小选择，本质上都是在“攒批”和“可控性”之间找平衡。
2. 批处理API的正确用法：addBatch、executeBatch、clearBatch
2.1 Statement批处理和PreparedStatement批处理的区别
JDBC规范的批处理API只有三件套：addBatch()、executeBatch()、clearBatch()。用Statement也能写批处理，但我强烈建议一律用PreparedStatement。
原因有几层。第一，SQL注入问题，真实项目里几乎不可能手工拼SQL去执行批量操作。第二，PreparedStatement在addBatch时只保存参数，不重复保存整条SQL字符串，内存开销远小于Statement。第三，它可以利用数据库的预编译特性，解析只做一次。批处理场景本来就是海量数据，任何一份多余的内存或解析开销都会被放大。
2.2 可复制的批处理代码框架
下面这段代码是一个可以直接用的框架，我本地的MySQL 8.0实测过基本逻辑没问题。关键点我都写在注释里。
String jdbcUrl = "jdbc:mysql://localhost:3306/test_db" + "?rewriteBatchedStatements=true" + "&useServerPrepStmts=true"; String user = "root"; String password = "password"; try (Connection conn = DriverManager.getConnection(jdbcUrl, user, password)) { conn.setAutoCommit(false); String sql = "INSERT INTO user (name, age, email) VALUES (?, ?, ?)"; try (PreparedStatement ps = conn.prepareStatement(sql)) { int batchSize = 1000; int total = 10000; for (int i = 1; i <= total; i++) { ps.setString(1, "user_" + i); ps.setInt(2, 20 + (i % 50)); ps.setString(3, "user_" + i + "@example.com"); ps.addBatch(); if (i % batchSize == 0) { ps.executeBatch(); conn.commit(); } } // 最后不足一批的余数也要刷出去 int remainder = total % batchSize; if (remainder != 0) { ps.executeBatch(); conn.commit(); } } } catch (SQLException e) { e.printStackTrace(); }几个容易被忽略的小细节：
- alternated clearBatch？其实executeBatch执行后，PreparedStatement内部会自动清空已执行过的参数，所以我这里没有手动调clearBatch。如果某个驱动版本表现异常，可以在executeBatch之后补一个ps.clearBatch()，无害。
- 最后一批余数必须补一次executeBatch，否则剩余数据会一直留在客户端缓冲区，永远不落库。
- 每批执行后立刻commit，避免事务过长。后面第4章会专门讲这个点的原因。
2.3 executeBatch的返回值到底怎么读
executeBatch返回一个int数组，数组里第i个元素对应第i条SQL的影响行数。如果某个驱动拿不到具体行数，可能是Statement.SUCCESS_NO_INFO，这个值是-2，别把它当成错误。
真正的坑出现在抛异常时。当某一条或某几条SQL执行失败，驱动会抛BatchUpdateException，很多人一看报错就直接回滚，但问题是：前面的语句可能已经执行成功了。想准确判断，得先拿到异常对象里的updateCounts数组。数组里值为EXECUTE_FAILED（-3）的那些下标，就是执行失败的语句编号。
try { int[] results = ps.executeBatch(); } catch (BatchUpdateException e) { int[] counts = e.getUpdateCounts(); for (int i = 0; i < counts.length; i++) { // counts[i] == -3 表示第i条执行失败，其余都是成功或者无信息 } }如果业务上要求“要么全成功，要么全失败”，那就别依赖这种判断，直接事务回滚最稳妥。但如果你做的是“跳过坏数据继续导入”的脏数据清洗任务，这个方法就能派上大用场了。
3. 藏起来的加速开关：rewriteBatchedStatements和其他驱动参数
3.1 为什么有人写了批处理却不提速
我见过很多同学，代码写得完全正确，addBatch、executeBatch一个不少，但一压测发现和逐条插入耗时差不多，于是得出“JDBC批处理没用”的结论。这个结论其实是冤枉了JDBC规范，真正的问题出在MySQL驱动上。
MySQL的Connector/J在默认情况下，并不会把你攒好的批处理合并成一条SQL发给服务端。它只是把参数保存在客户端，逐条调用服务端接口，也就是说网络往返次数依然是1万次，省掉的只是客户端一点点方法调用开销。这种状况下性能提升当然有限，大概只有百分之十几。
要让驱动真正合并SQL，必须手动打开一个参数：rewriteBatchedStatements=true。
3.2 批处理相关参数对照表
我在实际项目里常用的几个参数和效果列成一张表，方便你直接抄：
| 参数 | 作用 | 推荐值 | 说明 |
|---|---|---|---|
| rewriteBatchedStatements | 驱动将多条同构INSERT合并成多VALUES结构 | true | 批处理提速的关键开关，默认false |
| useServerPrepStmts | 是否使用服务端预编译 | true | 配合批处理可减少SQL重复解析 |
| allowMultiQueries | 允许一次发送多条语句 | false | 有注入风险，不建议日常开启 |
| useSSL | 是否使用SSL加密连接 | 按环境定 | 本地性能测试建议先关掉 |
rewriteBatchedStatements=true这条参数，MySQL官方文档对它的描述比较保守，说“可能提升性能”。实际测试下来，对小批量只有个位数百分比的提升，但在大批量INSERT场景，提升是数量级的——从几十秒压到几秒，甚至更快。
它做的事情很简单：把你addBatch进去的1000条同构INSERT，在驱动层重写成一条带多组VALUES的INSERT，比如：
-- 合并前 INSERT INTO user (name, age, email) VALUES (?, ?, ?); INSERT INTO user (name, age, email) VALUES (?, ?, ?); -- 合并后 INSERT INTO user (name, age, email) VALUES (?, ?, ?), (?, ?, ?), (?, ?, ?);数据库侧拿到一条语句，解析一次、执行计划生成一次，后面的工作全部集中处理。这才是批处理性能产生质变的真正原因。
3.3 不同数据库的批处理实现差异
这里多说一句，不是所有数据库驱动都需要手动开参数。PostgreSQL的JDBC驱动对批处理原生支持就很好，PGJDBC会直接把prepared statement的批量参数在协议层批量发送，性能提升明显。Oracle则需要设置批次相关的连接属性，且不同版本行为差异较大。SQL Server的批量写入场景，大部分人甚至会选择绕过JDBC批处理，直接走批量复制API。
如果你不限定MySQL，请务必先查一下所用数据库驱动对批处理的默认策略。很多“JDBC批处理没用”的结论，其实是在给特定驱动背锅。
4. 事务、批次大小与内存三者的平衡
4.1 事务边界是最容易被忽视的加速器
默认情况下，Connection是自动提交模式，每执行一条SQL就立即commit。就算你用了批处理，每调用一次executeBatch，驱动也会立刻提交一批，这样每一批都要等一次事务日志落盘。如果你把autoCommit关掉，攒够几批再commit一次，性能差异会非常明显。
但别走极端。有人图省事，插入10万条数据，一次性setAutoCommit(false)，全部执行完再commit。这样做的风险是：
- 事务持续时间过长，undo/redo日志急剧膨胀。
- 锁定的资源范围太大，这个事务会一直持有大量行锁，把其他读写的任务全堵死。
- 如果中途失败，回滚这个超大事务本身也是个耗时操作。
我的做法是每批次一commit，也就是代码示例里那个节奏：executeBatch一次，commit一次。这样事务边界清晰、日志可控，对性能的伤害也足够小。
4.2 批次大小：经验值之外还要看单行体积
批次大小怎么定，网上最多的建议是“100到1000条之间”。这个区间是对的，但它背后的逻辑值得说清楚。
批次太小，比如一次只addBatch10条，网络往返次数依然很多，驱动合并后的SQL也不够长，加速效果不明显。批次太大，比如一次攒10万条，客户端内存里会积压大量参数对象，数据库端的日志缓冲和行锁持有时间也会变长，性能可能不升反降。
还要考虑单条数据的实际体积。如果一行有十几个TEXT字段，每条SQL轻松超过1KB，那1000条一批意味着合并后一条SQL可能有1MB以上，底层Buffer明显吃紧。反过来，如果每行只有几个整数，5000条一批也完全没问题。
我压测时的习惯是：先定1000条为基准，再往大和往小各测一轮，看吞吐量和内存曲线的拐点在哪里。
4.3 一个通用的批量写入工具方法
把上面的选择固化成一个方法，方便复用。核心三要素：预编译、按批次刷出、每批次提交。
public static int batchInsert( Connection conn, List<List<Object>> rows, String insertSql, int batchSize) throws SQLException { int totalAffected = 0; boolean originalAutoCommit = conn.getAutoCommit(); conn.setAutoCommit(false); try (PreparedStatement ps = conn.prepareStatement(insertSql)) { for (int i = 0; i < rows.size(); i++) { List<Object> row = rows.get(i); for (int j = 0; j < row.size(); j++) { ps.setObject(j + 1, row.get(j)); } ps.addBatch(); if ((i + 1) % batchSize == 0) { int[] affected = ps.executeBatch(); conn.commit(); totalAffected += sum(affected); } } if (rows.size() % batchSize != 0) { int[] affected = ps.executeBatch(); conn.commit(); totalAffected += sum(affected); } return totalAffected; } finally { conn.setAutoCommit(originalAutoCommit); } }这个方法的想法很简单：任意表结构的INSERT都能套，前提是传入的列顺序要和SQL里的占位符顺序一致。注意finally里的setAutoCommit，不管成功还是失败，要把连接状态恢复到调用前来，避免连接池复用时光荣地留下一个自动提交关闭的僵尸连接。
5. 同一份数据三种写法：性能实测与踩坑记录
5.1 实测结果对比
我把同一份1万条数据用三种方式跑了一遍，数据库是本地单机MySQL 8.0，数据表就三个字段，记录到的耗时数值是相对值，不同机器上会不同，但比例关系很有参考价值。
| 写法 | 网络往返次数 | 服务端解析次数 | 实测耗时 |
|---|---|---|---|
| 逐条PreparedStatement插入 | 10000 | 10000 | 约35秒 |
| 批处理而不开rewrite | 10000 | 10000 | 约28秒 |
| 批处理 + rewriteBatchedStatements | 约10次 | 约10次 | 约1.2秒 |
| 批处理 + rewrite + 手动事务 | 约10次 | 约10次 | 约0.8秒 |
逐条插入和“假批处理”之间的差别很小，再次说明问题主要在网络往返，而不是驱动调用方式。开启rewrite后性能提升非常直观，这才是真正意义上批处理。手动事务又省了一部分落盘等待时间，因为commit次数从10000次降到了10次。
5.2 实操中的踩坑清单
第一坑：参数拼错。rewriteBatchedStatements连字符大小写都不能错，我第一次写的时候把Statements写成Statement，驱动没报错，参数静默不生效，性能死活上不去。检查办法很简单：跑批过程中打开数据库general log看SQL形态，如果看到的是一条条单VALUES的INSERT，说明参数没生效；如果是一条多VALUES的长SQL，就说明对了。
第二坑：批次太大导致内存溢出。我有一次在跑100万条数据的迁移任务时，图省事把所有数据先addBatch完再执行，结果JVM堆区飙到快3个G，系统GC频繁，卡到几乎假死。问题在于addBatch不是“记账”，是真的在每个PreparedStatement实例里保存了参数引用，海量数据下内存压力远比想象中大。
第三坑：BatchUpdateException部分成功。某次导入脏数据，其中几条违反了非空约束。因为开着事务，整体回滚是安全的，但日志里报错行数看着很困惑。后来发现正确做法是先用getUpdateCounts()判断哪些失败了，把失败数据的行号记下来，再做处理。
第四坑：把SELECT塞进批处理。批处理是用来提交INSERT、UPDATE、DELETE的，如果你不小心把查询语句也addBatch进去，轻则报错，重则得到混乱的结果集。有人可能会想“先查再改”合并成一个批次减少往返，完全不是一回事，查询和更新请分开。
5.3 批处理的常见认知误区
距离“会写批处理”还有几步的同学，通常会有这样几个误解：
- “批处理只是省掉SQL拼接的时间”。错，核心是网络往返次数和服务端解析次数的下降。
- “只要调了addBatch就会快”。错，MySQL要配合rewriteBatchedStatements才会质变。
- “批次越大越好”。错，太大内存吃不消，事务和锁也会失控。
- “批处理会自动排队、自动重试失败”。错，它就是单纯地批量发送，失败判断要自己处理。
如果你能避开这些点，批处理写出来基本就处于可用的状态了。
结尾
我记得最终调完那批数据写入任务时，最满意的其实不是三分钟这个数字，而是把整条链路的每一项都搞明白了：什么时候该攒批、一批攒多少、事务边界放在哪、驱动参数是不是真的生效。后来不管做什么批量导入任务，我习惯上来先问自己三个问题——单批次多少条、rewrite开关有没有打开、事务边界在哪里。想清楚这三个问题，JDBC批处理基本不会掉链子。
最后再分享一个排障小技巧：当你不确定批处理到底有没有生效时，别只盯着代码看。启动数据库的通用日志开关，或者跑批过程中用show processlist观察正在执行的SQL语句——如果看到的是一条条孤零零的单值INSERT，别怀疑，你的参数八成还是没配到位。看到一条多VALUES的大长SQL刷出来，那才算真正会飞了。
