MyBatis 批量插入优化：百万数据秒级导入-洪萨配资

作为一名奋战在一线的后端开发工程师，数据库批量操作是我们几乎每天都会遇到的场景。无论是数据迁移、定时报表计算，还是日志存档，我们都免不了要和“插入大量数据”打交道。

不知道你是否曾有过这样的经历：系统上线初期，数据量不大，一切风平浪静。然而随着业务扩张，某天你写了一个简单的for循环，调用mapper.insert()，准备插入几十万条数据。你点击了运行，然后去接了一杯咖啡，回来后发现程序还在跑；你吃完午饭回来，发现它居然还在跑！看着控制台那漫长的时间，你陷入了沉思：为什么这么慢？

在网络上，我们经常看到“MyBatis批量插入秒级导入百万数据”的说法。这到底是标题党的噱头，还是确有其事？今天，我们就抛开那些含糊其辞的言论，深入MyBatis与JDBC的底层，结合真实的实测数据（5万、10万、100万级别），彻底解开批量插入的性能之谜。

声明：本文所有结论均基于MySQL 8.0数据库、MyBatis 3.x/MyBatis-Plus框架以及JDBC驱动源码分析得出，数据来源均为开发者社区公开的实测记录及笔者验证，确保真实可靠。

第一章：直观的冲击——为什么“逐条插入”是性能杀手？

在开始优化之前，我们必须先认清“慢”的本质。很多新手最直观的写法，就是在Java代码中使用for循环，然后反复调用同一个插入方法。

这种写法在数据量较小时（如几十条）毫无感觉，但一旦数据量上升到5万条，灾难就降临了。

根据开发者社区的实测数据，使用for循环单条插入5万条数据，平均耗时达到了惊人的177秒（接近3分钟）。按照这个比例推算，插入100万条数据需要3540秒，也就是将近1个小时。

为什么这么慢？底层原理解析

这是由以下几个方面的开销叠加导致的：

网络传输的“惊群效应”
Java应用与MySQL数据库之间通过网络通信。每一次insert语句的执行，都相当于客户端给服务端发送一个“包裹”。发送5万个包裹，哪怕每个包裹只有1KB，光是网络IO的握手、传输、确认就要消耗大量的时间。网络延迟在高频交互下被急剧放大。
SQL解析的“重复造轮子”
在MySQL执行SQL前，需要经过词法解析、语法解析、生成执行计划等步骤。在逐条插入模式下，同样的SQL语句（只是值不同）被解析了5万次。MySQL查询缓存虽然能缓解，但对于写操作（Insert），缓存是失效的，这意味着这5万次解析完全是重复劳动。
事务提交的“刷盘压力”
在Spring Boot默认配置或手动编程事务中，每执行一条SQL，如果没有特殊配置，往往伴随着一次自动提交（AutoCommit=true）。这意味着每次插入不仅要写内存，还要确保日志写入磁盘。磁盘I/O是计算机中最慢的环节之一，5万次磁盘同步写操作足以拖垮任何高性能服务器。

结论：要想达到“秒级”导入，核心目标只有一个：尽一切可能减少Java程序与数据库之间的交互次数。

第二章：初窥门径——`foreach`拼接SQL的“大包干”模式

既然交互次数是瓶颈，最直观的解决方案就是：把多条SQL塞成一条超级大的SQL，一次性发过去。

这就是MyBatis中最常见的<foreach>标签批量插入方式。

1. 实现原理：将多次网络请求合并为一次

通过在Mapper.xml中编写动态SQL，将List集合中的循环直接拼接在values后面。

sql

INSERT INTO table (col1, col2) VALUES (1,2), (3,4), (5,6)...

2. 实测数据：性能的飞跃

同样是5万条数据的插入测试，使用拼接SQL的方式，耗时直接从177秒降低到了2.9秒左右。这个提升是质的飞跃，从“吃个饭回来还在跑”变成了“刚坐下就结束了”。

3. 隐藏的“深坑”：数据库报文大小限制与内存溢出

既然foreach这么强，是不是可以无脑用？并不是。当数据量达到百万级时，这种方法会暴露出严重的弊端。

SQL长度限制：MySQL数据库有一个max_allowed_packet参数（默认通常是4M）。当你一次性拼接的SQL字符串超过这个大小，数据库会直接拒绝连接或抛出异常。
真实案例：有开发者尝试使用foreach一次性插入10万条记录（涉及20多个字段），生成的SQL文本大小高达4.56M，直接触发了MySQL的PacketTooBigException。
解析复杂度指数级增长：并不是SQL越长越好。MyBatis底层在处理长SQL时，需要构建巨大的字符串并映射占位符。MySQL解析一个包含10万个values的语句，其内存消耗和解析时间是指数级上升的。有资料指出，当values数量超过5000后，性能曲线会急剧下跌。

小结：foreach适用于中小批量（如单次500-1000条）的数据同步，但绝对不能用于百万级的一次性导入。

第三章：官方秘籍——揭开`ExecutorType.BATCH`的神秘面纱

那么，既要减少网络交互，又要避免SQL体积爆炸，该怎么办？其实MyBatis早就提供了官方的解决方案——Batch Executor。

1. 重新认识MyBatis的执行器

MyBatis有三种内置的Executor类型（默认是SIMPLE）：

SIMPLE：每次执行都会创建一个新的预处理语句（PreparedStatement），执行完即关闭。这就是我们for循环慢的原因。
REUSE：会复用PreparedStatement，但依然是一条一条发往数据库。
BATCH：专门用于批量操作的执行器。

2. BATCH模式的工作原理

开启ExecutorType.BATCH后，MyBatis的行为发生了底层变化：

缓存SQL：当连续执行多条SQL时，如果SQL语句结构相同，MyBatis不会立即发送，而是将它们缓存在batch缓冲区中。
预编译优化：PreparedStatement只会被创建一次，后续的插入只是不断设置参数。
批量发送：当你调用sqlSession.commit()或达到一定数量时，MyBatis会一次性将这批参数连同SQL发送给数据库。

3. 实战测试：这才是“秒级”的真正含义

使用ExecutorType.BATCH模式，并关闭自动提交，插入5万条数据，实测耗时为1.7秒左右。

在更高量级的测试中（10万条数据），普通的saveBatch（MP默认实现）需要20秒，而开启了BATCH模式优化后，仅需5秒左右。这是目前公认的、在MyBatis框架下针对百万数据量级的最优解。

第四章：点睛之笔——`rewriteBatchedStatements`，被忽视的王牌参数

有时候，哪怕你用了上面的BATCH模式，发现性能并没有质的飞跃（比如只是从100秒变成了60秒），依然达不到秒级。这时候，90%的原因是你缺少了一个关键的JDBC参数：rewriteBatchedStatements=true。

1. 这就是为什么你的“批量”没生效

MySQL的JDBC驱动在默认情况下，出于对某些数据库兼容性或者保守策略的考虑，会忽略executeBatch()命令。当你调用addBatch()时，驱动心里想的是：“虽然你让我攒一批，但我还是习惯一条一条发给数据库。”

没有这个参数，你的BATCH模式只是把SQL攒在了一起，发送的时候依然是for循环发送。

2. 参数开启后的质变

在连接URL后面加上?rewriteBatchedStatements=true：

properties

jdbc:mysql://localhost:3306/test?rewriteBatchedStatements=true

开启后，JDBC驱动会做一件非常聪明的事情：它会把你的批量操作“重写”为一条原生的多重VALUES的Insert语句。

开启前：驱动向数据库发送Insert into ... values (?)+Insert into ... values (?)...
开启后：驱动将上述内容重写为Insert into ... values (?), (?) ...

对比数据：在未开启此参数时，10万条数据插入耗时约20秒；开启后，耗时骤降至5秒，甚至更优。这才是真正物理意义上的“合并发送”。

第五章：分而治之——百万级数据的架构策略

现在我们已经拿到了BATCH模式 +rewriteBatchedStatements这把利器。但在百万级数据面前，即便是最锋利的武器，也需要讲究战术。如果你试图在一个事务中一次性处理100万条数据，可能会遇到两个新问题：

内存溢出：List集合持有100万个对象，占用大量堆内存，引发频繁GC。
长事务陷阱：一个事务运行数十分钟，会导致Undo日志膨胀，甚至拖垮主从复制。

因此，对于百万级导入，我们必须引入“分片”思想。

1. 手动分片策略

原理很简单：将大List切分成若干个小List。

比如，我们要插入100万条数据，设置批次处理大小为1000。

将100万数据拆分成1000个“分片”。
对每个分片执行一次BATCH级别的插入操作。
每个分片单独开启和提交事务（或者批量提交事务）。

2. 批次大小的“黄金分割点”

批次大小（单次提交的记录数）并非越大越好。

过小（如10条）：网络交互次数依然很多，优势不明显。
过大（如10万条）：虽然网络交互少了，但单条SQL（即使使用BATCH）在数据库端执行时间过长，且会占用巨大的数据库内存。
最佳实践：经过大量测试，500条到2000条之间是性价比最高的区间。
- 若单行数据很小（如只有ID和Name），可偏向2000-5000条。
- 若单行数据很大（如包含Text或Blob字段），建议降低到500-1000条。

结论：百万数据导入 =分片逻辑+BATCH执行器+rewriteBatchedStatements=true。

第六章：实战中的避坑指南与“极端”优化

在实际生产环境中，除了上述核心配置，还有一些细节决定了最终的成败。

1. 自增主键回填的性能损耗

如果你需要在插入后获得数据库自动生成的主键ID（useGeneratedKeys=true），这会对批量插入产生一定的性能影响。因为数据库需要逐条生成ID并返回给客户端，破坏了“流式”传输的连续性。

优化建议：如果你的导入场景只是归档数据（Log或流水），且不需要立即获取ID，可以考虑在数据库层面不依赖自增ID，或者使用雪花算法在客户端提前生成ID。这能微幅提升批量插入效率。

2. 表结构与索引的取舍

索引的代价：插入数据时，数据库不仅要写数据，还要更新索引（B+Tree）。数据量越大，索引维护的开销越大。
优化方案：对于超大数据的离线导入（ETL），一种极端优化是：先删除或禁用索引，导入数据，重建索引。在百万级数据场景下，这种方式往往比边插边建索引快得多。

3. 调整MySQL数据库参数

为了让数据库承受住批量写入，需要配合调整MySQL配置：

innodb_buffer_pool_size：设置足够大，尽可能容纳数据和索引，减少磁盘I/O。
innodb_log_file_size：增大日志文件大小，减少日志切换带来的检查点开销。
max_allowed_packet：如果使用foreach方案（虽然不推荐），必须调大此参数以容纳大SQL。

第七章：不同方案的横向对比与选型建议

为了给你一个更直观的参考，我们将几种方案整理为下表（基于10万条数据）：

方案	实现方式	耗时（约）	优点	缺点	适用场景
逐条插入	for + insert	350秒+	实现简单	极慢，资源消耗大	严禁使用于批量场景
MyBatis-Plus	saveBatch()	20秒	无需写SQL，开箱即用	默认配置下性能不佳	中小规模数据，对性能不敏感
拼接SQL	`<foreach>`	3-10秒	比逐条快，直观	受SQL长度限制，大数据量内存爆炸	单次1000条以内的小批量
终极BATCH	BATCH + rewrite	2-5秒	性能最优，资源可控	需手动配置，需注意分片	生产环境大规模数据迁移首选

结语：回归业务的本质

经过一系列的技术拆解，我们可以看到，所谓“百万数据秒级导入”并非天方夜谭。从底层的网络IO、预编译原理，到JDBC驱动的隐藏参数，再到架构层的分片策略，每一步优化都有扎实的理论依据。

在追求性能的道路上，我们往往热衷于寻找“银弹”。但希望这篇文章能让你明白，真正的优化没有银弹，只有对底层原理的深刻理解。

下次当你面对海量数据插入任务时，请记住这几步：

丢掉for循环单条插入。
拥抱ExecutorType.BATCH。
检查JDBC URL中的rewriteBatchedStatements=true。
记得将列表分片提交。

希望这篇博客能帮助你彻底解决MyBatis批量插入的性能痛点，让你在处理大数据时更有底气。如果你在实际调优中遇到了奇葩的“坑”，欢迎在评论区留言交流。

MyBatis 批量插入优化：百万数据秒级导入