深入解析MyBatisPlus批量插入性能瓶颈与优化实战

1. MyBatisPlus批量插入的性能陷阱第一次用MyBatisPlus的saveBatch方法时我以为找到了批量插入的终极解决方案。直到某天凌晨3点收到报警短信看到监控图表上那条直冲天花板的数据库响应曲线才发现自己掉进了伪批量插入的坑里。当时我们的物联网平台每秒要处理上千条传感器数据理论上1500条/批的插入操作应该很轻松结果MySQL服务器CPU直接飙到100%。打开MyBatisPlus 3.4.3的源码saveBatch方法的真面目让人哭笑不得public boolean saveBatch(CollectionT entityList, int batchSize) { return executeBatch(entityList, batchSize, (sqlSession, entity) - { sqlSession.insert(sqlStatement, entity); }); }这哪里是批量插入分明是把List拆成单个对象循环insert虽然通过sqlSession.flushStatements()做了分批提交但本质上还是在用单条SQL反复操作。就像用卡车运沙子表面上看是一车一车地拉实际上每次只运一粒沙。真正的性能杀手在于JDBC的默认行为。即使你配置了batchSizeMySQL驱动在不开启rewriteBatchedStatements参数时会把executeBatch()自动拆解成单条语句执行。这就好比你去快餐店点10个汉堡服务员不是一次性给你而是做完一个递一个再做一个再递一个...2. 揭开rewriteBatchedStatements的神秘面纱在JDBC连接串加上rewriteBatchedStatementstrue后奇迹发生了。同样的5万条数据插入时间从15秒降到3秒。这个参数到底对SQL做了什么魔法开启后JDBC驱动会把多条INSERT语句重写成单条多值语法/* 改写前 */ INSERT INTO user(name) VALUES(a); INSERT INTO user(name) VALUES(b); /* 改写后 */ INSERT INTO user(name) VALUES(a),(b);但要注意三个关键点驱动版本必须使用MySQL Connector/J 5.1.13以上批处理大小建议每批1000-3000条太大反而会降低性能事务控制批量操作要放在同一个事务中避免自动提交我在测试环境做了组对比实验参数配置5万条数据耗时网络请求次数默认参数15.2s50000仅rewriteBatchedStatements3.1s50全优化配置2.7s13. 真正的批量插入方案rewriteBatchedStatements只是解决了JDBC层的问题MyBatisPlus自身的saveBatch仍然存在循环插入的缺陷。好在官方提供了InsertBatchSomeColumn注入器这才是SQL层面的真批量插入。实现步骤比想象中简单3.1 自定义SQL注入器public class MySqlInjector extends DefaultSqlInjector { Override public ListAbstractMethod getMethodList(Class? mapperClass) { ListAbstractMethod methodList super.getMethodList(mapperClass); methodList.add(new InsertBatchSomeColumn( field - field.getFieldFill() ! FieldFill.UPDATE)); return methodList; } }3.2 扩展BaseMapper接口public interface CommonMapperT extends BaseMapperT { int insertBatchSomeColumn(Param(list) ListT batchList); }3.3 配置类注册注入器Configuration public class MybatisPlusConfig { Bean public MySqlInjector sqlInjector() { return new MySqlInjector(); } }现在你的Mapper就拥有了真正的批量插入能力。看下SQL日志会发现本质区别-- saveBatch生成的SQL INSERT INTO user(name) VALUES(a); INSERT INTO user(name) VALUES(b); -- insertBatchSomeColumn生成的SQL INSERT INTO user(name) VALUES(a),(b);4. 高并发场景下的分批策略直接使用insertBatchSomeColumn有个致命问题——它不支持分批插入。当你要插入10万条数据时会生成包含10万个VALUES的超级SQL很可能超过MySQL的max_allowed_packet限制。参考MyBatisPlus的saveBatch思路我改造了个支持分批的增强版Transactional(rollbackFor Exception.class) public boolean saveBatchEnhanced(CollectionT entityList, int batchSize) { ListT batchList new ArrayList(); int count 0; for (T entity : entityList) { batchList.add(entity); if (count % batchSize 0 || count entityList.size()) { baseMapper.insertBatchSomeColumn(batchList); batchList.clear(); } } return true; }这个方案结合了两种优势每批数据通过insertBatchSomeColumn走真正的批量插入通过batchSize控制每批数据量避免SQL过长在百万级数据插入测试中这种方案比原生saveBatch快5-8倍。特别是在物联网设备高频上报数据的场景下1500条/批的插入耗时稳定在600-800毫秒再也没出现过Kafka消费者被踢出组的尴尬情况。5. 性能优化实战对比为了验证不同方案的实效我在相同环境下做了组对照实验测试数据50万条设备记录方案总耗时平均批次耗时内存消耗原生saveBatch78s1560ms低仅rewriteBatchedStatements32s640ms低insertBatchSomeColumn全量14s280ms高分批insertBatchSomeColumn16s320ms中事实证明结合rewriteBatchedStatements和分批处理的insertBatchSomeColumn是最优解。虽然全量插入的理论速度最快但在生产环境风险太高。我的建议是开发环境可以用全量插入方便测试生产环境务必采用分批策略建议batchSize设为1000-3000配合连接池参数调优maxPoolSize、minIdle等最后分享个真实案例某智能家居平台接入10万台设备后每日数据量达到2亿条。采用优化方案后批量插入耗时从原来的平均4秒降到800毫秒服务器资源消耗降低60%。这告诉我们批量操作无小事性能优化往往就在这些基础细节里。