autocommit=1会使每条insert成为独立事务，导致重复解析、加锁、写日志、刷盘和索引维护，大幅增加i/o与cpu开销；必须设autocommit=0并显式用start transaction/commit批量提交，才能发挥多值insert和组提交优势。
autocommit=1 会让每条 INSERT 都变成独立事务
MySQL 默认 autocommit=1，意味着你没显式写 BEGIN 或 START TRANSACTION，每条 INSERT 就自动开启、执行、提交一个事务。这不是“批量写入”，而是“1000 次单行写入”，每次都要走完整流程：解析 SQL → 加锁 → 写 redo log → 刷盘（受 innodb_flush_log_at_trx_commit 控制）→ 更新索引 B+ 树 → 释放锁 → 清理 binlog cache。
常见错误现象包括：SHOW PROCESSLIST 看到大量线程卡在 query end 或 commit；监控里 Innodb_log_waits > 0；插入耗时随行数线性增长，毫无批量收益。
- 确认当前行为：
SELECT @@autocommit;—— 生产环境几乎总是1 - 别依赖 ORM 框架的默认连接配置（比如 Spring 的
@Transactional只包业务逻辑，不包纯数据导入） - 导入脚本开头加
SET autocommit = 0;，结尾统一COMMIT;，中间所有 INSERT 共享同一个事务上下文
刷盘开销被放大 1000 倍
当 innodb_flush_log_at_trx_commit = 1（默认），每次事务提交都触发一次 fsync()。机械盘单次耗时 5–15ms，SSD 也要 0.2–1ms。插 10 万行，就是 10 万次磁盘强制刷写 —— 不是瓶颈在“写数据”，而是在“等磁盘确认”。
哪怕你用 INSERT INTO t VALUES (),(),()... 一次插 1000 行，只要没包裹在事务里，MySQL 仍按 1000 个事务处理，fsync 也执行 1000 次。
-
innodb_flush_log_at_trx_commit = 2：日志只写进 OS cache，不fsync，崩溃可能丢 1 秒数据，但导入速度可从 17 分降到 1 分内 -
= 0更快，但 MySQL 进程崩溃就会丢最近 1 秒所有事务，生产环境慎用 - 必须配合
autocommit = 0+ 显式COMMIT，否则=2也无效
索引维护成本随事务数指数级上升
每条 INSERT 都要更新主键 B+ 树和所有二级索引 B+ 树。如果表有 5 个二级索引，autocommit=1 下插 1 万行 = 维护 5 万棵 B+ 树分支；而用 1 个事务插 1 万行，B+ 树分裂、页重分配、父节点更新等操作仍发生，但锁持有时间更集中、内存局部性更好，整体开销远低于分散执行。
尤其当主键是非递增字段（如 VARCHAR(36) 的 UUID），B+ 树分裂频率极高，autocommit=1 会让 CPU 和 I/O 被反复打断，无法形成有效吞吐。
- 主键用
BIGINT AUTO_INCREMENT+ 按主键顺序插入 → 分裂极少 - 导入前临时
DROP INDEX非必要二级索引，导入完成再重建，比边插边建快 3–8 倍 -
ALTER TABLE t DISABLE KEYS对 InnoDB 5.7+ 有限支持，但不如显式删索引可控
binlog cache 不攒批，反而加剧写放大
在开启 binlog 的场景下（如主从复制、备份），每个会话有自己的 binlog cache。当 autocommit=1，每条 INSERT 后就立即把生成的 binlog event 写入磁盘文件；而显式事务中，所有 DML 的 binlog events 会累积在 cache 中，直到 COMMIT 才一次性刷出 —— 这才是 MySQL 原生的组提交（Group Commit）生效前提。
如果 sync_binlog = 1 且 innodb_flush_log_at_trx_commit = 1，但事务太小、太碎，binlog 线程根本等不到足够多事务“凑组”，只能退化为单事务刷盘，白白浪费组提交机制。
- 确保
binlog_group_commit_sync_delay = 100（微秒），给其他并发事务留出“搭车”窗口 -
binlog_group_commit_sync_no_delay_count = 10：积压满 10 个事务就强制刷，避免低流量下卡死 - 别设
sync_binlog = 0来换速度 —— 它绕过组提交逻辑，还可能导致主从数据不一致
autocommit=1 这个底层执行模型问题，其他优化都是在给漏水的桶补漆。
