【金仓数据库征文】MyBatis批量写入的三种实现对比：十万级数据导入的吞吐量榨取

文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程3.1 方案一for 循环单条插入反面教材3.2 方案二MyBatis XML foreach 拼接隐患极大4. 方案实施JDBC 原生 Batch 与事务边界调优4.1 数据库驱动适配 (核心秘籍)4.2 ORM 层与事务控制SqlSession 批量提交5. 结果对比5.1 耗时对比图5.2 内存波动与吞吐量图表5.3 核心指标数据表6. 风险与复盘每日一句正能量生命有限与其过拧巴日子不如把时间用在能让我们变得更好的事情上。“拧巴”是什么是内耗是纠结是做着自己不喜欢的事却不敢改变是明明可以放下却反复咀嚼痛苦。减去那些消耗你却不滋养你的事把时间腾出来给那些让你成长、让你发光的事情。1. 背景与问题在现代企业级应用中数据字典同步、Excel 海量报表导入以及物联网设备数据采集等场景都离不开“批量写入”操作。最近我们的系统在接手一批 10 万级的历史订单数据迁移时业务端反馈系统直接卡死随后引发了灾难性的系统崩溃。经过排查分析我们发现原系统在处理批量插入时存在严重的技术缺陷网络 I/O 风暴最初的开发人员使用了最原始的for循环单条插入导致 10 万次网络 TCP 往返Round-trips耗时超过 5 分钟。OOM (内存溢出) 与 SQL 解析阻断后来开发人员尝试将代码改为 MyBatis 的foreach动态标签拼接 SQL。结果在一次性传入 10 万条数据时不仅触发了 MySQL 的max_allowed_packet拦截还导致 JVM 内存瞬间被打满触发 Full GC 甚至 OOM 宕机。如何优雅、高效且安全地将海量数据持久化成为了摆在我们面前的紧迫痛点。2. 环境与数据为了客观对比不同批量写入方案的极限吞吐量我们搭建了以下标准测试环境数据库服务器: MySQL 8.0.32 (InnoDB, Buffer Pool Size: 2GB)应用框架: Spring Boot 2.7.x, MyBatis 3.5.10数据库驱动:mysql-connector-j-8.0.33.jar压测数据: 单次导入 100,000 条OrderImportRecord数据。初始化表结构 (schema.sql):CREATETABLEt_order_import(idBIGINTPRIMARYKEYCOMMENT雪花ID,order_noVARCHAR(64)NOTNULL,user_idBIGINTNOTNULL,amountDECIMAL(10,2)NOTNULL,import_timeDATETIMEDEFAULTCURRENT_TIMESTAMP)ENGINEInnoDBDEFAULTCHARSETutf8mb4;3. 复现过程为了找到最佳实践我们将完整实现并对比三种常见的批量写入方式观察它们的底层行为与性能瓶颈。3.1 方案一for循环单条插入反面教材这是最容易想到的实现方式但性能极其惨烈。在默认的事务隔离级别下如果不加Transactional每次insert都会自动开启并提交事务Auto-Commit产生极大的磁盘 Redo Log 刷盘开销。// 极度不推荐产生 N 次网络 IO 和 N 次事务提交publicvoidinsertOneByOne(ListOrderImportlist){for(OrderImportorder:list){orderMapper.insert(order);}}3.2 方案二MyBatis XMLforeach拼接隐患极大通过 MyBatis 的动态 SQL 标签生成形如INSERT INTO table VALUES (...), (...), (...)的巨型 SQL 语句。insertidinsertBatchByXmlINSERT INTO t_order_import (id, order_no, user_id, amount) VALUESforeachcollectionlistitemitemseparator,(#{item.id}, #{item.orderNo}, #{item.userId}, #{item.amount})/foreach/insert隐患暴露当传入 10 万条数据时MyBatis 在解析这个巨大的 AST 语法树时直接消耗了数百 MB 的堆内存。随后生成的 SQL 字符串长达数兆字节MBMySQL 服务端直接抛出异常Packet for query is too large (X bytes max_allowed_packet)。这导致该方案只能分批进行如每 1000 条拼接一次但仍无法避免极高的内存垃圾产生。4. 方案实施JDBC 原生 Batch 与事务边界调优真正的企业级标准答案是方案三利用 JDBC 的 Batch 机制配合ExecutorType.BATCH。此方案不会拼接巨型 SQL而是预编译一条 SQL 模板将参数分批发送给数据库。要让它真正发挥威力必须在驱动层、ORM层和事务边界三个维度进行深度调优。4.1 数据库驱动适配 (核心秘籍)在 MySQL 中原生 JDBC 默认会一条一条发送批量参数。必须在 URL 中追加rewriteBatchedStatementstrue驱动才会在底层网络传输时真正将它们打包发送application.yml配置:spring:datasource:# 必须开启 rewriteBatchedStatementstrue 才能实现真正的 JDBC 批量网络封包url:jdbc:mysql://192.168.1.100:3306/trade_db?rewriteBatchedStatementstrueuseServerPrepStmtstrueusername:adminpassword:Password1234.2 ORM 层与事务控制SqlSession批量提交我们需要绕过 Spring 注入的默认单次 Mapper通过SqlSessionFactory开启一个专门的ExecutorType.BATCH类型的会话。同时为了防止 10 万条数据在一个大事务中耗尽 Undo Log 并长时间锁表我们设计了每 2000 条强制 Flush 并提交的边界控制。优化后的 Service 代码:Slf4jServiceRequiredArgsConstructorpublicclassBatchImportService{privatefinalSqlSessionFactorysqlSessionFactory;// 不使用 Transactional而是进行编程式的精细化事务边界控制publicvoidimportOrdersInBatch(ListOrderImportorderList){// 开启 Batch 模式的 SqlSession并关闭自动提交try(SqlSessionsqlSessionsqlSessionFactory.openSession(ExecutorType.BATCH,false)){OrderMappermappersqlSession.getMapper(OrderMapper.class);intbatchSize2000;// 每 2000 条进行一次网络发送和事务提交for(inti0;iorderList.size();i){mapper.insert(orderList.get(i));// 触发表征上的批量执行边界if((i1)%batchSize0||iorderList.size()-1){try{// 1. flushStatements 真正触发 JDBC 驱动的网络批量发送sqlSession.flushStatements();// 2. 提交事务释放这批数据的数据库锁和内存sqlSession.commit();// 3. 清理本地缓存防止大量插入导致内存泄漏sqlSession.clearCache();}catch(Exceptione){sqlSession.rollback();log.error(Batch insertion failed at record index: {},i,e);// 处理 BatchUpdateException 可定位到具体哪一条数据出错thrownewRuntimeException(Import failed during batch commit.,e);}}}}}}5. 结果对比我们将 10 万条数据分别通过上述三种方案进行落库压测以下是吞吐量与耗时的直观对比。(为保证标准化以下图表文本均采用英文说明)5.1 耗时对比图0180036005400720090001080012600144001620018000For Loop (Auto-Commit)XML Foreach (Chunks of 1k)ExecutorType.BATCH (2k/commit)Method 1Method 2Method 3100,000 Records Insertion Time Comparison执行耗时对比甘特图5.2 内存波动与吞吐量图表渲染错误:Mermaid 渲染失败: Lexical error on line 3. Unrecognized text. ... x-axis [Method 1 (For Loop), Method 2 -----------------------^ 吞吐量图表5.3 核心指标数据表实现方案网络交互次数执行耗时 (10万条)堆内存峰值消耗数据库服务器 CPU 负载方案一For 循环100,000 次~ 185,000 ms极低 (无积压)高 (频繁事务创建销毁)方案二XMLforeach(按1000切片)100 次~ 3,200 ms极高 (触发数次 Full GC)中 (解析超长 SQL 耗费 CPU)方案三ExecutorType.BATCH(按2000提交)50 次~ 480 ms极低 (流式处理)极低 (预编译模板复用)结论方案三ExecutorType.BATCHrewriteBatchedStatementstrue在 TPS 上相比传统foreach标签提升了近6.6 倍并且完美规避了 JVM 内存爆炸的风险是当之无愧的最优解。6. 风险与复盘在实际落地ExecutorType.BATCH时有以下几点极其容易被忽视的“暗坑”需要我们在架构设计时重点设防MySQL 驱动的封包骗局如果你配置了ExecutorType.BATCH但忘记在 JDBC URL 中加上rewriteBatchedStatementstrueJDBC 驱动依然会在底层一条一条地发送INSERT语句给 MySQL 服务器这是无数开发者都会踩的坑必须在配置复查时严格核对。大事务与长锁风险 (Long Transaction Blocking)批量插入 10 万条数据时如果将整个过程包裹在一个Transactional中会导致这 10 万条数据的表锁或间隙锁长期不释放阻塞其他业务的写入。必须采用如上文所示的编程式事务利用sqlSession.commit()按批次如 1000 或 2000 条进行局部提交及时释放锁资源。异常捕获与断点续传在执行flushStatements()时可能会抛出BatchUpdateException。如果是唯一索引冲突或字段超长引起的中断系统需要能够解析该异常定位到具体失败的行号并将其写入死信队列或错误日志表以便人工介入或后续重试。转载自https://blog.csdn.net/u014727709/article/details/163505635欢迎 点赞✍评论⭐收藏欢迎指正