为什么大批量SQL INSERT很慢以及如何做性能优化？-SQL-PHP中文网

真正快的批量插入往往绕开INSERT语句本身，优先用INSERT...SELECT或LOAD DATA INFILE直通存储引擎，跳过SQL解析层；同时需关闭autocommit、避免触发器、控制单批5000行以内。

为什么大批量sql insert很慢以及如何做性能优化？

大批量 INSERT 慢，90% 不是 SQL 写得不对，而是数据库在“边写边整理”——每插一行，它就在更新索引、检查触发器、刷日志、等锁。

为什么单条 INSERT 拼成 VALUES() 还是慢？

你以为把 1000 行合并成一条 INSERT INTO t (a,b) VALUES (),(),... 就万事大吉？不一定。MySQL 仍要为每一行执行完整的插入流程：校验约束、定位 B+ 树位置、分裂页、写 redo log、触发器逐行执行……它不是“批量执行”，而是“批量提交”。

如果表上有 3 个二级索引，插入 1 行 = 写主键索引 + 写 3 个二级索引，共 4 次随机写入
若某索引字段基数极低（如 status TINYINT），B+ 树频繁页分裂，IO 放大更明显
max_allowed_packet 默认 4MB，拼太多行会直接报错 Packets larger than max_allowed_packet are not allowed，别硬堆到 5000 行

触发器让 INSERT 变成 N×慢，而不是慢一点

哪怕是个空触发器，也会强制事务串行化；而含 SELECT 或 JSON 解析的触发器，在批量插入时开销直接乘以 N。

INSERT INTO t SELECT * FROM s LIMIT 10000 → 触发器执行 10000 次，不是 1 次
触发器里写 json_extract(NEW.payload, '$.user_id')？10 万行 = 10 万次 JSON 解析，无缓存、不复用
用 IF EXISTS(SELECT 1 FROM ref WHERE id = NEW.ref_id) 做校验？批量下只查第一行，其余静默通过，逻辑错误

autocommit=ON 是隐形性能杀手

默认开启时，每条 INSERT 都是独立事务：写 redo、刷盘、释放锁、清理事务状态——光日志刷盘就可能卡住整条链路。

查当前状态：SHOW VARIABLES LIKE 'autocommit'，结果为 ON 就是隐患
正确做法：显式 BEGIN / COMMIT 包裹批量操作，或连接串加 ?useSSL=false&autoReconnect=true&rewriteBatchedStatements=true（JDBC 场景）
注意：长事务不能太长，否则阻塞 purge 线程、拖慢 MVCC，建议单批控制在 5000 行以内

真正快的批量插入，往往绕开 INSERT 语句本身

当数据来自文件或 staging 表，INSERT ... SELECT 和 LOAD DATA INFILE 能跳过 SQL 解析层，直通存储引擎。

INSERT INTO t SELECT * FROM staging WHERE batch_id = 123：数据不出库，无网络传输，但需确保 staging.batch_id 有索引
LOAD DATA INFILE '/tmp/data.csv'：比等量 INSERT 快 5–10 倍，但要求文件在 MySQL 服务端，且需 FILE 权限
如果用 MyBatis，务必确认连接参数含 rewriteBatchedStatements=true，否则 addBatch() 仍是逐条发送

最易被忽略的一点：慢 INSERT 很少单独发生。它常和 Page cleaner took XXXms 错误日志、Lock wait timeout exceeded 或 query end 状态一起出现——这时候问题已经不在 SQL，而在磁盘吞吐、buffer pool 大小或上游大事务积压。先看 error.log，再动 SQL。