MyBatis-Plus批量插入性能调优实战：从BatchExecutor配置到自定义SQL，手把手搞定万级数据入库
MyBatis-Plus批量插入性能调优实战：从BatchExecutor配置到自定义SQL，手把手搞定万级数据入库
当系统需要处理海量数据入库时，批量插入性能往往成为瓶颈。最近在重构一个数据同步服务时，发现原本需要3小时完成的百万级数据入库，经过优化后仅需18分钟。这种量级的性能提升并非魔法，而是基于对MyBatis-Plus底层机制的深度理解和正确配置。
1. 为什么默认的批量插入并不"批量"
很多开发者第一次使用MyBatis-Plus的saveBatch方法时，会误以为它自动实现了真正的批量插入。直到查看数据库日志才发现，所谓的"批量"操作竟然生成了成千上万条独立的INSERT语句。
1.1 性能测试对比
我们通过一个简单的测试来验证默认行为：
// 生成1万条测试数据 List<User> users = IntStream.range(0, 10000) .mapToObj(i -> new User("user" + i, 20 + i % 10)) .collect(Collectors.toList()); // 测试saveBatch性能 long start = System.currentTimeMillis(); userService.saveBatch(users); System.out.println("耗时：" + (System.currentTimeMillis() - start) + "ms");典型测试结果：
- 默认配置：约3200ms
- 理想状态：<500ms
1.2 SQL执行真相
查看数据库日志会发现，实际执行的是：
INSERT INTO user (name,age) VALUES ('user1', 20); INSERT INTO user (name,age) VALUES ('user2', 21); -- 重复1万次...这种逐条插入的方式会产生巨大的性能开销，主要包括：
- 每次插入都需要建立网络连接
- 数据库需要重复解析相似的SQL语句
- 事务管理带来的额外开销
2. 深度解析批量插入机制
2.1 MyBatis-Plus执行流程剖析
跟踪saveBatch的源码，可以发现关键执行路径：
ServiceImpl.saveBatch → SqlHelper.executeBatch → SqlSession.insert核心问题在于默认使用的SimpleExecutor会为每个实体生成独立的插入语句。即使使用了批量方法，底层仍然是循环执行单条插入。
2.2 批量执行的三种模式
MyBatis支持三种执行器类型：
| 执行器类型 | 特点 | 适用场景 |
|---|---|---|
| SimpleExecutor | 每次执行都创建新Statement | 简单查询，默认配置 |
| ReuseExecutor | 复用预处理Statement | 频繁执行相同SQL |
| BatchExecutor | 批量提交多个Statement | 大批量写操作 |
3. 生产级优化方案实战
3.1 方案一：启用BatchExecutor
这是最简单的优化方式，只需修改配置：
mybatis-plus: configuration: default-executor-type: batch global-config: db-config: logic-delete-field: isDeleted # 避免逻辑删除干扰优化效果：
- 1万条数据插入时间：3200ms → 850ms
- SQL变为真正的批量形式：
INSERT INTO user (...) VALUES (...),(...)
注意：使用BatchExecutor时需要确保事务正确管理，建议在Service层添加@Transactional注解
3.2 方案二：自定义批量SQL
对于极致性能要求的场景，可以手动编写批量插入SQL：
public interface UserMapper extends BaseMapper<User> { @Insert("<script>" + "INSERT INTO user (name, age) VALUES " + "<foreach collection='list' item='item' separator=','>" + "(#{item.name}, #{item.age})" + "</foreach>" + "</script>") void insertBatch(@Param("list") List<User> users); }性能对比：
- 1万条数据插入仅需420ms
- 网络请求次数从1万次降为1次
3.3 方案三：事务+分批提交
平衡性能和资源占用的折中方案：
@Transactional public void batchSave(List<User> users) { int batchSize = 1000; for (int i = 0; i < users.size(); i += batchSize) { List<User> subList = users.subList(i, Math.min(i + batchSize, users.size())); userService.saveBatch(subList); } }优势分析：
- 避免大事务导致的锁表问题
- 内存占用可控
- 兼容默认实现，代码改动小
4. 生产环境调优指南
4.1 连接池关键配置
使用HikariCP时的推荐配置：
spring: datasource: hikari: maximum-pool-size: 20 # 根据并发量调整 connection-timeout: 60000 max-lifetime: 18000004.2 监控指标与阈值
| 监控项 | 推荐阈值 | 监控工具 |
|---|---|---|
| 批量插入耗时 | <1s/千条 | Grafana + Prometheus |
| 数据库连接数 | <80%最大连接数 | Druid监控 |
| 事务锁等待时间 | <500ms | SHOW ENGINE INNODB STATUS |
4.3 失败重试机制
使用Spring Retry实现自动重试：
@Retryable(value = SQLException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000)) public void batchOperation() { // 批量操作逻辑 }5. 实战经验分享
在最近的一个电商订单归档项目中，我们最初使用默认的saveBatch方法，处理100万条数据需要近3小时。经过以下优化步骤：
- 首先启用BatchExecutor，时间缩短到45分钟
- 然后优化为自定义批量SQL，降至25分钟
- 最后调整连接池参数和分批大小，稳定在18分钟
关键发现是当批量大小超过5000时，数据库的响应时间会明显增加。经过多次测试，最终确定2000条/批是最佳平衡点。