1. MyBatis批量插入性能瓶颈解析第一次接触MyBatis批量插入是在三年前的一个电商项目当时需要每天凌晨导入百万级商品数据。最初采用简单的单条插入方式结果跑一次全量导入需要6个小时数据库服务器CPU直接飙到100%。这个惨痛教训让我开始深入研究MyBatis的批量插入优化。MyBatis默认的Simple执行器模式存在明显性能缺陷。它每次执行insert语句都会经历完整的生命周期解析SQL→参数映射→预编译→执行→提交。当处理10万条数据时这个流程会被重复10万次其中预编译阶段尤其消耗资源。我做过测试在MySQL 5.7环境下Simple模式插入1万条记录耗时约25秒。更糟糕的是某些场景下还会出现SQL语句洪水现象。比如使用foreach拼接SQL时如果一次性拼接5000条values生成的SQL可能达到几MB大小。不仅网络传输耗时数据库解析这么长的SQL也会消耗大量内存。曾经有个案例某系统批量插入时直接把数据库连接撑爆了。2. 经典优化方案ExecutorType.BATCH深度剖析ExecutorType.BATCH是我最早采用的优化方案它的核心原理可以用预编译复用来概括。开启BATCH模式后MyBatis会缓存预编译后的PreparedStatement后续插入只需替换参数值避免了重复预编译的开销。具体实现需要三个关键步骤// 1. 创建BATCH模式的SqlSession SqlSession session sqlSessionFactory.openSession(ExecutorType.BATCH); try { UserMapper mapper session.getMapper(UserMapper.class); // 2. 循环执行插入操作 for (User user : userList) { mapper.insert(user); } // 3. 统一提交 session.flushStatements(); session.commit(); } finally { session.close(); }这里有个容易踩的坑忘记调用flushStatements()。有次我批量插入10万数据内存直接OOM就是因为没有及时清空批处理缓存。最佳实践是每1000条左右flush一次既保证批处理效果又避免内存溢出。性能对比数据很能说明问题Simple模式1万条/25秒BATCH模式1万条/3.2秒foreach拼接1万条/1.8秒但内存消耗是BATCH的3倍3. 现代最佳实践MultiRowInsertStatementProvider详解随着MyBatis 3.5的推出MultiRowInsertStatementProvider成为了新的性能标杆。它通过动态SQL生成技术在保证可读性的同时实现了接近原生JDBC的性能。我在最近一个物联网项目中采用这种方案写入速度比传统BATCH模式又提升了40%。具体实现示例try (SqlSession session sqlSessionFactory.openSession()) { UserMapper mapper session.getMapper(UserMapper.class); ListUser users generateTestUsers(10000); MultiRowInsertStatementProviderUser insert insertMultiple(users) .into(user) .map(id).toProperty(id) .map(username).toProperty(username) .map(password).toProperty(password) .build() .render(RenderingStrategies.MYBATIS3); mapper.insertMultiple(insert); session.commit(); }这个方案的亮点在于自动优化SQL格式生成高效的批量插入语句内置参数绑定安全防护避免SQL注入支持类型处理器自动应用与MyBatis缓存机制完美兼容实测对比数据传统BATCH10万条/8.5秒MultiRowInsert10万条/5.2秒JDBC原生批处理10万条/4.9秒4. MyBatis-Plus的saveBatch魔法对于使用MyBatis-Plus的项目其saveBatch方法提供了开箱即用的批量插入方案。最近帮一个初创团队优化他们的CRM系统仅用saveBatch替换原有逻辑数据导入时间就从2小时缩短到15分钟。标准用法很简单ListUser userList generateUsers(100000); userService.saveBatch(userList);但有几个实用技巧值得分享合理设置batchSize参数默认是1000但根据我的测试在SSD存储的MySQL上设置为5000更优配合rewriteBatchedStatementstrue参数使用性能可再提升30%事务边界要明确建议在Service层添加Transactional我整理了一个性能对比矩阵方案10万条耗时CPU占用内存峰值单条插入285s85%1.2GBforeach拼接4.8s45%3.5GBBATCH模式6.2s38%800MBsaveBatch5.5s40%1.1GB5. 实战中的避坑指南在金融级应用中我们遇到过批量插入导致主从同步延迟的问题。当时采用BATCH模式每秒插入2万条记录结果从库延迟达到20分钟。解决方案是在JDBC URL添加useServerPrepStmtsfalse设置rewriteBatchedStatementstrue采用分片插入策略每5000条提交一次另一个常见问题是自增ID获取。在BATCH模式下必须等到事务提交后才能获取真实ID。有次我们实现订单拆单功能时就踩了这个坑。解决方案有两种// 方案1使用SELECT LAST_INSERT_ID()手动查询 Options(useGeneratedKeystrue, keyPropertyid) Insert(INSERT INTO orders(...) VALUES(...)) void insertOrder(Order order); // 方案2采用UUID等非自增主键 public class Order { private String id UUID.randomUUID().toString(); //... }对于超大批量数据千万级建议采用分段多线程处理。但要注意线程数不要超过数据库连接池大小否则会适得其反。我常用的线程池配置ThreadPoolExecutor executor new ThreadPoolExecutor( 5, // 核心线程数连接池最大连接数的一半 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(100), new ThreadPoolExecutor.CallerRunsPolicy() );6. 性能优化全链路实践完整的性能优化应该覆盖整个数据处理链路。在最近一个日志分析系统中我们通过全链路优化将吞吐量提升了15倍数据准备阶段使用ParallelStream快速转换数据格式预分配List容量避免扩容开销ListLog logs rawData.parallelStream() .map(this::convertToLog) .collect(Collectors.toList());数据库配置spring.datasource.hikari.maximum-pool-size20 spring.datasource.urljdbc:mysql://...rewriteBatchedStatementstruecachePrepStmtstrue运行时监控使用Micrometer记录关键指标设置合理的超时时间Transactional(timeout 30) public void batchInsert(ListData data) { //... }失败处理机制实现批量重试逻辑采用死信队列处理异常数据RetryTemplate retryTemplate new RetryTemplate(); retryTemplate.execute(context - { return batchOperation(); });这套方案在AWS c5.2xlarge实例上实现了每秒插入12万条的稳定吞吐量而且CPU占用保持在70%以下。关键是要根据实际业务场景调整各个阶段的参数没有放之四海而皆准的最优解。