autocommit=1导致批量INSERT慢3～5倍，因每条语句都触发完整事务流程（加锁→写redo log→刷盘→提交→释放锁），I/O与锁开销剧增；关闭autocommit并显式BEGIN/COMMIT才能真正提升性能。
因为 autocommit=1 时，每条写语句都强制走完整事务流程——加锁、写 redo log、刷盘、提交、释放锁，I/O 和锁开销被放大数倍，不是“稍慢”，而是批量插入常慢 3～5 倍。
autocommit=1 下单条 INSERT 实际发生了什么
很多人以为只是“执行一条 SQL”，其实 MySQL 在 autocommit=1 时会隐式做这些事：
- 为该语句单独开启一个事务上下文
- 对涉及行加行锁（或间隙锁）
- 生成并写入 redo log（即使未刷盘，也要调用
log_write()） - 触发
log_flush()刷盘（受innodb_flush_log_at_trx_commit=1控制） - 提交事务、释放锁、清理事务结构体
这个过程在 SSD 上单次耗时约 0.5–2ms，但高频小事务会让磁盘 I/O 和锁竞争成为瓶颈。MyISAM 表不受影响，因它不走这套日志+锁机制；InnoDB 表则直接受限于磁盘延迟和并发锁调度。
SET autocommit = 0 后为什么 BEGIN 还没用
只执行 BEGIN 不关 autocommit，等于没关——MySQL 仍会在每条语句后自动 COMMIT。验证方式很简单：SELECT @@autocommit; 返回 1 就说明开关没关掉。
常见错误现象包括：
- 执行了
BEGIN和 100 条INSERT，但没发COMMIT就断连 → 全部回滚，数据丢失 - 连接池复用下，前一次遗留
autocommit = 0+ 未提交事务，下次取到该连接的应用一执行UPDATE就卡住 -
INFORMATION_SCHEMA.INNODB_TRX中看到TRX_STATE = 'RUNNING'且TRX_STARTED时间异常早
连接池场景下最容易被忽略的陷阱
像 HikariCP、SQLAlchemy Pool 这类连接池不会重置会话变量。一次请求忘了 COMMIT 或 ROLLBACK，下一次从池里取出的连接就带着残留事务状态跑业务逻辑。
典型表现是：
- 第一次请求正常，第二次执行
SELECT FOR UPDATE立即阻塞 - 监控发现
Threads_running突增，但慢查询日志里找不到对应 SQL - 反复出现
Lock wait timeout exceeded（错误码 1205）
规避方式必须由应用层兜底：无论成功失败，请求结束前强制 COMMIT 或 ROLLBACK；数据库侧配合设 wait_timeout（如 60 秒），让空闲长事务自动断连。
真正伤性能的从来不是 BEGIN 这个词本身，而是每条语句背后那套不可省略的 redo 写入、锁管理、刷盘动作——关掉 autocommit 只是第一步，后续必须配对 COMMIT，否则事务卡住比性能慢更致命。
