MySQL为何推荐短事务以减少垃圾回收和锁的负面影响？

本文共计955个文字，预计阅读时间需要4分钟。

简而言之，事务不是建议，而是MySQL正常运行的底层要求。 长事务会占用 +undo 日志回收、拖死 +purge 线程、让锁一直不放，最终导致 +SELECT 等操作变慢。

长事务为何卡住 undo 日志回收

undo 日志不能被 purge 线程清理，根本原因不是“时间长”，而是它没提交——只要事务还活跃，InnoDB 就得保留它开始前所有数据的旧版本，供其他事务做 MVCC 快照读。这会导致：

• innodb_undo_tablespaces 磁盘空间持续上涨，甚至填满（尤其开启 innodb_undo_log_truncate=ON 但无活跃事务触发 truncate 时）
• 历史版本链变长，SELECT 扫描 undo 链耗时增加，information_schema.INNODB_TRX 里 trx_started 时间越久，影响越明显
• purge 线程忙于跳过这些“钉子事务”对应的记录，实际清理进度停滞，SHOW ENGINE INNODB STATUS 中可见 Purge done for trx's n:o < [low watermark] 长期不推进

锁为什么迟迟不释放

InnoDB 的行锁、间隙锁（Gap Lock）和 Next-Key Lock 全部绑定在事务生命周期上，不是语句执行完就释放。一个未提交的事务哪怕只执行了一条 UPDATE users SET status=1 WHERE id=123，它持有的锁就会一直挂着：

• 其他事务想更新同一行？Waiting for lock 直接卡住
• 想插入 id=122 或 id=124？间隙锁可能拦住，引发幻读防护级阻塞
• DDL 操作（如 ALTER TABLE）会被卡在 Waiting for table metadata lock，因为元数据锁需要所有活跃事务释放才能获取
• 监控里 innodb_row_lock_time_avg 和 innodb_row_lock_waits 会明显跳升

如何快速定位正在作祟的长事务

别等报警，日常就得查。以下命令直击要害：

SELECT trx_id, trx_mysql_thread_id AS thread_id, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

重点关注 duration_sec > 60 的记录，结合 trx_state 判断是否卡在外部调用或慢查询上。如果 trx_query 是 NULL，说明事务处于空闲状态（比如应用层开了事务但忘了提交），此时 KILL [thread_id] 通常能立即生效；若状态是 ROLLING BACK，只能等——改 innodb_fast_shutdown 也没用。

真正管用的防御手段不在数据库侧

监控和 KILL 是兜底，防不住人为失误。关键要从应用层掐断源头：

• 禁止在事务里做 HTTP 调用、文件读写、sleep、复杂计算——这些操作不产生数据库日志，却白白占着锁和 undo
• ORM 层（如 MyBatis、GORM）避免隐式开启长事务，检查 @Transactional 注解作用域是否过大
• 批量更新必须分页提交，单次事务控制在 1000 行以内，配合 innodb_lock_wait_timeout=50 防雪崩
• 连接池配置需匹配事务预期时长，比如 HikariCP 的 connection-timeout 和 max-lifetime 要略大于最长业务事务，避免连接被池误杀导致事务悬挂

最易被忽略的一点：即使全是只读 SELECT，显式开启事务（BEGIN）也会创建 read view 并加入活跃事务链表——这种“伪长事务”在报表类场景中大量存在，一样拖慢 purge 和内存回收。