MyBatis-Plus批量插入与多线程性能优化实战
1. 项目背景与核心问题
在数据密集型的Java应用中，批量数据插入是常见的性能瓶颈场景。以用户行为日志、交易记录、传感器数据等为例，单条插入的数据库IO开销会成为系统吞吐量的致命短板。MyBatis-Plus作为MyBatis的增强工具，提供了saveBatch批量操作方法，但开发者常困惑于其与多线程方案的性能差异。
实测场景：需要将5000条设备状态记录持久化到MySQL。单条插入耗时约50ms，理论总耗时应为250秒——这显然不可接受。本文将对比分析两种优化方案：
- 方案A：直接使用
saveBatch批量插入 - 方案B：通过线程池分片执行
saveBatch
2. 技术方案深度解析
2.1 MyBatis-Plus批量保存机制
saveBatch底层通过JDBC的rewriteBatchedStatements参数实现真批量操作。当开启该参数时（MySQL需在连接字符串添加rewriteBatchedStatements=true），驱动程序会将多个INSERT语句重写为单条多值语法：
/* 原始语句 */ INSERT INTO device_log VALUES(...); INSERT INTO device_log VALUES(...); /* 重写后 */ INSERT INTO device_log VALUES(...),(...);关键参数说明：
batchSize：控制每批提交的记录数，默认1000continueOnError：批量失败时是否继续
重要提示：MySQL的max_allowed_packet参数需调整（建议16MB以上），否则大批量插入会报包大小超限错误
2.2 多线程分片方案设计
线程池配置核心参数：
ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, // 核心线程数 10, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue<>(100), // 任务队列 Executors.defaultThreadFactory(), new ThreadPoolExecutor.AbortPolicy() );数据分片策略示例：
// 将5000条数据分为5个分片（每个1000条） List<List<DeviceLog>> shards = Lists.partition(dataList, 1000); // 提交分片任务 List<Future<Integer>> futures = new ArrayList<>(); for (List<DeviceLog> shard : shards) { futures.add(executor.submit(() -> deviceLogService.saveBatch(shard))); } // 等待所有任务完成 for (Future<Integer> future : futures) { future.get(); }3. 性能对比实测
测试环境：
- 硬件：4核CPU/8GB内存
- 数据库：MySQL 8.0.26（innodb_buffer_pool_size=4G）
- 网络：本地回环
测试数据：
| 方案 | 1000条 | 5000条 | 10000条 |
|---|---|---|---|
| 单条插入 | 48s | 241s | 486s |
| saveBatch(默认) | 1.2s | 3.8s | 7.5s |
| 多线程+saveBatch(5线程) | 0.9s | 2.1s | 3.8s |
关键发现：
- 批量操作比单条插入快40倍以上
- 多线程方案在数据量>3000条时优势明显
- 线程数并非越多越好（测试显示4-6线程为最佳区间）
4. 生产环境注意事项
4.1 事务边界控制
多线程方案中，每个saveBatch操作应在独立事务中执行。推荐使用Spring的PROPAGATION_REQUIRES_NEW传播级别：
@Transactional(propagation = Propagation.REQUIRES_NEW) public void saveBatchInNewTransaction(List<DeviceLog> list) { deviceLogMapper.saveBatch(list); }4.2 失败处理机制
建议实现以下容错策略：
- 记录失败分片信息
- 设置重试机制（如使用Spring Retry）
- 死信队列存储最终失败记录
4.3 线程池调优公式
最佳线程数估算：
线程数 = CPU核心数 * (1 + 平均等待时间/平均计算时间)对于典型的数据库IO操作（等待时间约10ms，计算时间约2ms）：
4核 * (1 + 10/2) = 24线程但需考虑数据库连接池大小限制（如Druid默认maxActive=8）
5. 进阶优化方案
5.1 混合批处理模式
结合JDBC原生批量与多线程：
// 每个线程使用原生Statement批量 @Transactional public void nativeBatchInsert(List<DeviceLog> list) { SqlSession session = sqlSessionTemplate.getSqlSessionFactory().openSession(ExecutorType.BATCH); DeviceLogMapper mapper = session.getMapper(DeviceLogMapper.class); list.forEach(mapper::insert); session.commit(); }5.2 动态分片策略
根据数据特征自动调整分片大小：
int dynamicBatchSize = Math.max(100, 5000 / Runtime.getRuntime().availableProcessors());5.3 监控指标埋点
建议监控：
- 批次执行时间分布（Prometheus Histogram）
- 线程池队列积压情况
- 数据库QPS与连接数
6. 典型问题排查
6.1 批量插入变慢
检查点：
- 确认
rewriteBatchedStatements=true已生效 - 检查是否有唯一索引冲突
- 监控数据库锁等待情况（
SHOW ENGINE INNODB STATUS）
6.2 多线程数据错乱
解决方案：
- 使用ThreadLocal存储线程上下文
- 确保实体类无共享状态
- 对公共资源加锁（如Redis分布式锁）
6.3 内存溢出风险
预防措施：
- 限制单批次数据量（建议不超过5000条）
- 采用流式分片读取（如使用MyBatis的Cursor）
- 设置JVM最大堆内存（-Xmx）为数据量的3倍以上
通过以上对比可见，对于5000条级别的数据插入，多线程+saveBatch组合方案比纯批量插入可再提升40%-50%性能。但在实际应用中，建议根据具体硬件配置、数据库负载、业务容忍度等因素进行针对性调优。