MyBatis批量插入性能跃迁：从20分钟到6秒的实战调优指南
当数据量突破万级时，原本流畅的系统突然变得举步维艰——这是我们团队最近遭遇的真实生产事故。一张包含23列的表，单次插入1.2万条记录竟耗时超过20分钟，直接导致夜间批处理任务无法按时完成。本文将完整还原这次性能攻坚的全过程，不仅展示最终解决方案，更重要的是分享一套可复用的性能问题分析方法论。
1. 问题现场与初步诊断
那是一个普通的周四凌晨，监控系统突然发出警报：数据同步任务已持续运行23分钟，远超平时3分钟的平均水平。我们立即抓取了关键指标：
// 原始插入代码片段 public int batchInsert(List<DataRecord> records) { return sqlSessionTemplate.insert("com.example.mapper.DataMapper.batchInsert", records); }对应的Mapper XML配置：
<insert id="batchInsert" parameterType="java.util.List"> INSERT INTO data_table (field1, field2, ..., field23) VALUES <foreach collection="list" item="item" separator=","> (#{item.field1}, #{item.field2}, ..., #{item.field23}) </foreach> </insert>通过JDBC日志分析，发现了三个关键现象：
- SQL语句长度超标：生成的SQL超过1.5MB，MySQL服务器需要额外时间解析
- 网络传输瓶颈：单条SQL包含所有数据，导致网络传输时间占比高达40%
- 内存压力：MyBatis在拼接SQL时消耗了过量堆内存
关键发现：当列数超过20且记录数破万时，foreach方式的性能呈指数级下降
2. 优化方案深度对比
我们测试了四种主流批量插入方案，在相同数据量（1.2万条23列记录）下的表现：
| 方案 | 执行时间 | 内存消耗 | 代码改动量 | 事务控制难度 |
|---|---|---|---|---|
| 原生foreach | 23min | 高 | 低 | 简单 |
| 分批foreach | 2.1min | 中 | 中 | 中等 |
| ExecutorType.BATCH | 8.4s | 低 | 高 | 复杂 |
| MyBatis-Plus批量 | 6.2s | 低 | 低 | 简单 |
2.1 分而治之：foreach分批策略
将大数据集拆分为每批100条的小数据集：
public int optimizedBatchInsert(List<DataRecord> records) { int batchSize = 100; int count = 0; List<DataRecord> batch = new ArrayList<>(batchSize); for (DataRecord record : records) { batch.add(record); if (batch.size() == batchSize) { count += sqlSessionTemplate.insert("batchInsert", batch); batch.clear(); } } if (!batch.isEmpty()) { count += sqlSessionTemplate.insert("batchInsert", batch); } return count; }优化效果：
- 执行时间从23分钟降至2分钟左右
- 内存峰值降低60%
- 网络传输时间占比降至15%
2.2 JDBC批处理模式
启用真正的批处理需要两个关键配置：
- MyBatis执行器类型切换：
SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH); try { DataMapper mapper = session.getMapper(DataMapper.class); for (DataRecord record : records) { mapper.insertSingle(record); } session.flushStatements(); session.commit(); } finally { session.close(); }- JDBC连接参数必须包含：
rewriteBatchedStatements=true&useServerPrepStmts=false注意事项：
- 批量模式下无法立即获取自增ID
- 需要手动管理事务边界
- 建议配合连接池使用，避免频繁创建连接
3. MyBatis-Plus的降维打击
在Spring Boot项目中，MyBatis-Plus提供了开箱即用的批量方案：
@Service public class DataServiceImpl extends ServiceImpl<DataMapper, DataRecord> { @Transactional public boolean superBatchInsert(List<DataRecord> records) { return saveBatch(records, 1000); // 每批1000条 } }其核心优势在于：
- 自动优化批处理大小
- 内置事务管理
- 支持多种数据库方言
- 简洁的API设计
底层实现关键点：
// MyBatis-Plus批处理核心逻辑 SqlHelper.executeBatch(entityClass, log, list, batchSize, (sqlSession, entity) -> { sqlSession.insert(statement, entity); });4. 原理级优化策略
4.1 数据库层面配置
MySQL性能关键参数：
# 连接池配置 spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.minimum-idle=5 # JDBC参数 spring.datasource.url=jdbc:mysql://host:3306/db? useSSL=false& rewriteBatchedStatements=true& useServerPrepStmts=false& cachePrepStmts=true& prepStmtCacheSize=250& prepStmtCacheSqlLimit=20484.2 对象转换优化
避免在循环中进行复杂计算：
// 反例：每次循环都执行耗时操作 records.forEach(r -> { r.setHash(computeHash(r)); // 耗时操作 mapper.insert(r); }); // 正例：预处理所有数据 records = records.stream() .peek(r -> r.setHash(computeHash(r))) .collect(Collectors.toList()); batchInsert(records);4.3 监控与调优工具链
推荐的生产级监控方案：
SQL监控：
- 启用MyBatis SQL日志：
logging.level.org.mybatis=DEBUG - 使用P6Spy捕获真实SQL
- 启用MyBatis SQL日志：
性能分析：
// 简单计时工具 StopWatch watch = new StopWatch(); watch.start("batchInsert"); // 执行插入操作 watch.stop(); log.info("执行耗时：{}ms", watch.getTotalTimeMillis());高级工具：
- Arthas实时诊断
- JProfiler内存分析
- Prometheus + Grafana监控看板
5. 多维方案选型指南
根据不同的业务场景，我们总结出以下决策矩阵：
中小规模数据（<5000条）：
- 方案：foreach单批处理
- 优势：实现简单，无需特殊配置
- 配置示例：
<insert id="batchInsert"> INSERT INTO table VALUES <foreach item="item" collection="list" separator=","> (#{item.field1},...) </foreach> </insert>
大规模数据（>1万条）：
- 方案：MyBatis-Plus批量+rewriteBatchedStatements
- 优势：性能接近JDBC原生批处理，开发效率高
- 代码示例：
@Transactional public void largeScaleImport(List<Data> data) { // 自动分批，每批1000条 mybatisPlusService.saveBatch(data, 1000); }
超大规模数据（>10万条）：
- 方案：ExecutorType.BATCH+自定义分批
- 关键技巧：
// 每5000条提交一次 int batchSize = 5000; SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH); try { for (int i = 0; i < records.size(); i++) { mapper.insert(records.get(i)); if (i % batchSize == 0 && i > 0) { session.flushStatements(); } } session.commit(); } finally { session.close(); }
6. 避坑指南与最佳实践
在实际落地过程中，我们总结了这些经验：
事务边界控制：
- 批量操作必须显式管理事务
- 建议事务隔离级别设为READ_COMMITTED
连接池配置：
spring: datasource: hikari: maximum-pool-size: 20 connection-timeout: 30000 max-lifetime: 1800000异常处理：
try { batchOperation.execute(); } catch (MyBatisSystemException e) { // 处理批处理特有异常 if (e.contains(BatchUpdateException.class)) { // 提取失败记录 } }性能验证脚本：
@Test void testBatchPerformance() { List<DataRecord> testData = generateTestData(15000); StopWatch watch = new StopWatch(); watch.start("foreach"); nativeBatchInsert(testData); watch.stop(); watch.start("mybatis-plus"); mybatisPlusBatchInsert(testData); watch.stop(); System.out.println(watch.prettyPrint()); }
经过三个迭代周期的优化，我们的批处理任务最终稳定在6秒左右完成，较最初的20分钟提升了200倍。这个案例最宝贵的不是某个具体方案，而是教会我们：性能优化必须建立在准确测量和分析的基础上，没有放之四海而皆准的银弹。
