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：控制每批提交的记录数，默认1000
• continueOnError：批量失败时是否继续

重要提示：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）
• 网络：本地回环

测试数据：

关键发现：

1. 批量操作比单条插入快40倍以上
2. 多线程方案在数据量>3000条时优势明显
3. 线程数并非越多越好（测试显示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 失败处理机制

建议实现以下容错策略：

1. 记录失败分片信息
2. 设置重试机制（如使用Spring Retry）
3. 死信队列存储最终失败记录

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 监控指标埋点

建议监控：

1. 批次执行时间分布（Prometheus Histogram）
2. 线程池队列积压情况
3. 数据库QPS与连接数

6. 典型问题排查

6.1 批量插入变慢

检查点：

1. 确认rewriteBatchedStatements=true已生效
2. 检查是否有唯一索引冲突
3. 监控数据库锁等待情况（SHOW ENGINE INNODB STATUS）

6.2 多线程数据错乱

解决方案：

1. 使用ThreadLocal存储线程上下文
2. 确保实体类无共享状态
3. 对公共资源加锁（如Redis分布式锁）

6.3 内存溢出风险

预防措施：

1. 限制单批次数据量（建议不超过5000条）
2. 采用流式分片读取（如使用MyBatis的Cursor）
3. 设置JVM最大堆内存（-Xmx）为数据量的3倍以上

通过以上对比可见，对于5000条级别的数据插入，多线程+saveBatch组合方案比纯批量插入可再提升40%-50%性能。但在实际应用中，建议根据具体硬件配置、数据库负载、业务容忍度等因素进行针对性调优。