千万级数据批量插入不能仅依赖mybatis-plus的savebatch或insertbatchsomecolumn，因其默认逐条拼sql、易触发max_allowed_packet限制和oom；应分层优化：sql层用insert ... values(),()合并+事务包裹，数据库层关闭非必要日志与索引，应用层分片+重试+监控。
直接上结论：千万级数据批量插入，不能只靠 MyBatisPlus 的 saveBatch 或 insertBatchSomeColumn——它默认仍是逐条拼 SQL、受 max_allowed_packet 和事务粒度限制，不加改造极易 OOM 或超时；真正安全高效的做法，是分层控制：SQL 层用 INSERT INTO ... VALUES (), (), ... 合并 + 事务包裹，数据库层关掉非必要日志和索引，应用层做分片+重试+监控。
为什么 saveBatch 默认不安全？
MyBatisPlus 的 saveBatch 默认会把全部数据一次性加载进 JVM 内存，再生成一条超长 SQL。遇到 50 万条记录、每条 200 字节，光 SQL 字符串就超 100MB，直接触发 MySQL 的 max_allowed_packet（默认 64MB），报错 Packets larger than max_allowed_packet are not allowed。更糟的是，它默认不开启事务，每条 INSERT 都走独立事务，WAL 日志刷盘频繁，IO 扛不住。
实操建议：
- 必须显式传入
batchSize参数，例如mapper.insertBatchSomeColumn(list, 1000)，强制每 1000 条切一次批次 - 调用前手动开启事务：
@Transactional(rollbackFor = Exception.class)，避免自动提交放大锁竞争 - 禁用 MyBatisPlus 的自动生成主键逻辑（如
@TableId(type = IdType.AUTO)），改用数据库自增或雪花 ID，减少主键冲突与回滚风险
INSERT INTO ... VALUES (), () 的长度和性能边界
MySQL 允许单条 INSERT 包含多组 VALUES，这是最轻量、兼容性最好的批量方式。但它有硬限制：不能超过 max_allowed_packet，且过长会导致 SQL 解析变慢、网络传输易中断。
实操建议：
- 按 500–1000 行/条 控制每条 SQL 的
VALUES数量（不是行数，是括号组数），例如INSERT INTO t (a,b) VALUES (1,2),(3,4),...,(999,1000) - 上线前务必检查并调大
max_allowed_packet（建议设为 256M），否则即使你本地拼得好，到生产库也会被截断 - 避免在
VALUES中嵌套子查询或函数，纯数据值最稳；若有动态字段（如NOW()），统一用数据库默认值或DEFAULT关键字代替
导入前必须关闭的 3 个 MySQL 配置
千万级插入本质是写密集型操作，InnoDB 的默认配置全是为“读写混合”设计的，对纯写反而拖后腿。不关它们，速度可能差 3–5 倍。
实操建议（执行前在当前 session 设置）：
- 关唯一性检查：
SET unique_checks=0（导入完再开，否则约束失效） - 关外键检查：
SET foreign_key_checks=0（确保目标表无外键依赖，或确认源数据已校验） - 调低日志刷盘频率：
SET innodb_flush_log_at_trx_commit=2（接受最多 1 秒日志丢失，但换回 3–10 倍写入速度）
注意：这些设置仅对当前连接生效，不影响其他业务连接；但必须配对恢复，否则后续业务可能出数据一致性问题。
LOAD DATA INFILE 是最快的，但也是最容易翻车的
LOAD DATA INFILE 是 MySQL 原生命令，绕过 SQL 解析层，直接从文件流灌数据，实测比拼接 SQL 快 5–10 倍。但它要求文件在数据库服务器本地（或启用 local_infile 客户端开关），且格式严格、错误处理弱。
实操建议：
- 先用
SELECT ... INTO OUTFILE导出模板验证字段顺序、分隔符、NULL 表示法（如\N） - 导入前确保目标表无触发器（
TRIGGER），否则会被跳过且不报错 - 必须确认
secure_file_priv路径，否则报错The MySQL server is running with the --secure-file-priv option so it cannot execute this statement - 别用它导入带敏感字段（如密码哈希）的数据——文件落地即暴露，不符合安全审计要求
真正难的从来不是“怎么快”，而是“怎么不出错”。千万级插入失败一次，重跑成本远高于优化 10% 速度。所以分片大小、事务粒度、错误日志落盘、中间状态标记（比如用 Redis 记录已处理 offset），这些细节比选哪个 API 更关键。
