根本原因在于innodb_flush_log_at_trx_commit=1与autocommit=1组合导致每条insert作为独立事务强制刷盘；正确做法是显式开启事务（begin/start transaction）后批量提交，避免隐式事务和连接池遗留事务隐患。
autocommit=1 时每条 INSERT 都强制刷盘
根本原因不在“事务”本身，而在 innodb_flush_log_at_trx_commit=1（默认值）与 autocommit=1 的组合：每条 INSERT 都被当作独立事务，触发一次完整的 redo log 写入 + 强制刷盘（log_flush()）。磁盘 I/O 次数直接等于行数，而不是批量合并后的一次刷盘。
常见错误现象：
- 插入 1 万行耗时 8 秒，关 autocommit 后降到 1.8 秒
-
SHOW ENGINE INNODB STATUS中看到大量LOG等待 -
Information_schema.INNODB_METRICS里os_file_reads远高于预期
SET autocommit = 0 不等于性能自动提升
只是关闭开关，不开启事务，也不减少 I/O。真正起作用的是把多条语句包进一个显式事务再 COMMIT。否则即使 autocommit = 0，单条 INSERT 执行完仍处于未提交状态，锁不释放、undo log 持续增长，且应用断连后全丢——这叫隐式事务，不是优化，是隐患。
实操关键点：
-
SET autocommit = 0后必须跟BEGIN或START TRANSACTION，否则后续 DML 不会真正持锁或记日志 - 验证是否生效：
SELECT @@autocommit;必须返回0；SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;应能看到活跃事务 - ORM 如 MyBatis 配了
autoCommit=false但没加@Transactional，就掉进隐式事务陷阱
连接池场景下 autocommit=0 更危险
像 HikariCP、SQLAlchemy Pool 这类连接池不会重置会话变量。如果上一次使用遗留了 autocommit = 0 + 未 COMMIT 的事务，下一次取出该连接的应用代码，哪怕只执行一条 SELECT ... FOR UPDATE，也会立刻阻塞。
典型表现：
- 第一次请求正常，第二次请求 UPDATE 直接超时
-
INFORMATION_SCHEMA.INNODB_TRX中TRX_STATE = 'RUNNING'且TRX_STARTED时间异常早 - 监控发现
Threads_running突增，但慢查询日志为空
规避方式：
- 应用层强制兜底：无论成功失败，都确保
COMMIT或ROLLBACK - 数据库侧设
wait_timeout = 60，让空闲长事务自动断连 - 定期巡检：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 30;
批量写入的合理事务粒度是多少
不是越大越好。事务过大会导致 undo log 膨胀、锁升级（如行锁升为表锁）、主从延迟加剧，甚至触发 OOM。
实测建议：
- 单批控制在
100–1000行较稳妥 - 30 万行数据：一次性
COMMIT最快；每 10 万行提交一次仅慢 1.17%；但每 100 行提交一次就慢 24.44%；每行提交一次慢 546.78% - 避免在事务中混入 DDL（如
CREATE TABLE），它会隐式触发COMMIT，提前提交前面所有 DML
真正卡住性能的，从来不是 BEGIN 这个词，而是没关 autocommit 导致它形同虚设；更隐蔽的问题，是连接池里那些没人收尾的事务，它们不报错，只悄悄拖慢一切。
