MyBatis在Spring Boot中批量插入万级数据若不配rewriteBatchedStatements=true、不切ExecutorType.BATCH、不控制事务边界，性能必超10秒；根本原因在于JDBC默认逐条处理、重复解析、频繁刷盘及网络往返，而非代码逻辑问题。
MyBatis 在 Spring Boot 中批量插入万级数据，不配 rewriteBatchedStatements=true、不切 ExecutorType.BATCH、不控制事务边界，性能必然卡在 10 秒以上——这不是代码问题，是 JDBC 层和 MySQL 协议默认行为的叠加结果。
为什么 MyBatis 默认 foreach 插入还是慢？
很多人以为用了 INSERT 拼成一条 SQL 发出去（如 INSERT INTO t VALUES (),(),()），但 JDBC 驱动仍按单条语句处理：每条值元组都走一次参数绑定、一次网络包发送、一次服务端解析。MySQL 并不会因此跳过重复解析或日志刷盘。
- 拼接式
@Transactional） - SQL 长度受限（MySQL 默认
max_allowed_packet=4MB），插 5000+ 行容易直接报Packet for query is too large - 没有利用 JDBC Batch 的底层能力：预编译复用、本地缓冲、批量 flush
必须开启的 JDBC 连接参数：rewriteBatchedStatements
这是 MySQL Connector/J 提供的开关，作用是让驱动在检测到 addBatch() 调用时，自动把多条 INSERT 重写为一条带多值的语句，并绕过服务端重复解析。不开它，ExecutorType.BATCH 几乎无效。
在 application.yml 中确保 URL 包含该参数：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
spring:
datasource:
url: jdbc:mysql://localhost:3306/test?rewriteBatchedStatements=true&useSSL=false&serverTimezone=UTC
- 仅对
INSERT和REPLACE生效，UPDATE/DELETE不支持 - MySQL 5.7+ 和 8.0 都支持，但 Connector/J 版本需 ≥ 5.1.29 或 8.0.12
- 若用 Druid，还需额外配
druid.connection-properties: rewriteBatchedStatements=true
切换 ExecutorType.BATCH 的两种可靠方式
MyBatis 默认用 SIMPLE 执行器，每次 insert() 都新建 Statement；换成 BATCH 后，会复用 PreparedStatement 并累积到 addBatch() 缓冲区，直到 flushStatements() 或事务提交才真正发往数据库。
- 全局配置（推荐）：在
@Configuration类中设置SqlSessionFactoryBean.configuration.defaultExecutorType = ExecutorType.BATCH - 局部控制：用
sqlSessionFactory.openSession(ExecutorType.BATCH)获取会话，手动commit()，注意不能交给 Spring 自动管理事务（否则会提前 flush） - 别信
mybatis-plus的saveBatch()：它默认仍是循环 + flush 每 1000 条，没开rewriteBatchedStatements时性能无质变
事务粒度与 batchSize 的实际取舍
把 1 万条塞进一个事务看似最省，但风险高：锁持有时间长、redo log 累积大、OOM 概率上升。实测更稳的策略是分片提交，比如每 500–1000 条一提交。
- 太小（如 100）：事务提交次数仍多，fsync 开销未明显降低
- 太大（如 5000）：InnoDB undo log 增长快，可能触发
Lock wait timeout exceeded或主从延迟突增 - 真实建议：配合 HikariCP 的
connection-timeout和 MySQL 的innodb_log_file_size调整，优先保稳定而非极限吞吐
最容易被忽略的是：无论用哪种方案，都得关掉 MyBatis 的 configuration.logImpl = NO_LOGGING，否则 DEBUG 级 SQL 日志本身就能吃掉一半耗时。
