autocommit=1 时批量 insert 明显更慢，因每条语句都触发完整事务流程（加锁→写 redo log→强制刷盘→提交→释放锁），i/o 与锁开销剧增；关闭 autocommit 并显式 begin/commit 才能真正提升性能。
autocommit=1 时批量 INSERT 明显更慢，尤其在 InnoDB 表上 —— 不是“有点慢”，而是常达 3～5 倍差距。这不是配置微调问题，而是事务生命周期和日志刷盘机制的根本差异。
autocommit=1 下每条 INSERT 都触发完整事务流程
MySQL 默认开启 autocommit，这意味着哪怕只执行一条 INSERT，也会走一遍：加锁 → 写 redo log → 调用 log_write() → 强制 log_flush() 到磁盘（受 innodb_flush_log_at_trx_commit=1 控制）→ 提交 → 释放锁。
常见错误现象：
- 插入 1 万行耗时 8 秒，而关掉 autocommit 后只要 1.8 秒
-
SHOW ENGINE INNODB STATUS中看到大量LOG等待，OS file reads次数远高于预期
关键点：
- MyISAM 表基本不受影响，因为不依赖事务日志
- InnoDB 表的性能损耗集中在磁盘 I/O 和锁持有频次上
- 即使单行插入，也逃不开
log_flush()开销（除非你改了innodb_flush_log_at_trx_commit）
SET autocommit = 0 后必须显式 COMMIT，否则连接会卡住
执行 SET autocommit = 0 只是关闭自动提交开关，它不会自动开启事务；后续 DML 会进入“隐式事务上下文”，但直到你执行 BEGIN 或 START TRANSACTION 才真正持锁、记日志。真正的性能提升来自把多条语句包进一个事务再 COMMIT。
容易踩的坑：
- 只设
autocommit = 0却忘了COMMIT，该连接后续所有查询都卡在未结束事务里 - 连接池复用时，前一次没
ROLLBACK，下一次取出的连接仍处于事务中，SELECT ... FOR UPDATE直接阻塞 -
INFORMATION_SCHEMA.INNODB_TRX里能看到TRX_STATE = 'RUNNING'且TRX_STARTED时间异常早
实操建议：
- 批量写入前统一执行：
SET autocommit = 0; BEGIN; - 单批控制在 100–1000 行，避免事务过大导致 undo log 膨胀或锁升级
- 异常分支必须配对
ROLLBACK，不能只依赖连接断开自动回滚
连接池场景下 autocommit=0 更危险，也更需要规范
像 HikariCP、SQLAlchemy Pool 这类连接池不会重置会话变量。如果某次使用后遗留了 autocommit = 0 + 未提交事务，下次从池里取到这个连接的应用代码，可能在毫无察觉的情况下把本该自动提交的操作拖进长事务。
典型表现：
- 第一次请求正常，第二次请求执行
UPDATE就超时 - 监控发现
Threads_running突增，但慢查询日志里没对应 SQL -
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX显示多个长时间 RUNNING 的事务
解决方案：
- JDBC：用
connection.setAutoCommit(true)显式恢复，而非依赖初始值 - Python（PyMySQL/MySQLdb）：每次获取连接后执行
conn.autocommit(True)，或在连接池配置里设autocommit=True - 避免在 init_connect 里全局设
autocommit=0，它对只读连接也生效，纯属埋雷
最常被忽略的其实是事务边界意识：autocommit 控制的是“提交时机”，不是“是否开启事务”。关了它却不 COMMIT，等于把锁、日志、内存都占着不放——性能没提上来，先搞出了阻塞和资源泄漏。
