SQL 长事务为何如此危险？

长事务会导致锁阻塞、MVCC清理受阻和主从延迟。它持续持有行/表级锁，阻塞其他操作；阻碍undo log回收，引发磁盘膨胀与性能下降；使binlog大事务串行回放，加剧主从延迟；需通过INFORMATION_SCHEMA.INNODB_TRX主动监控并优先kill空闲长事务。

长事务会持续持有锁，阻塞其他操作

数据库在事务执行期间，会对涉及的行、页甚至表维持锁（如 SELECT ... FOR UPDATE 持有行级写锁，UPDATE 在未提交前不释放锁）。只要事务没 COMMIT 或 ROLLBACK，这些锁就一直挂着。

常见表现是：其他会话执行相同记录的 UPDATE 或 SELECT FOR UPDATE 时卡住，等待超时后报错 Lock wait timeout exceeded；或者 SHOW PROCESSLIST 看到一堆 Locked 状态的线程。

• 即使只是执行了 SELECT 后没关闭连接，也可能因事务未结束而持锁（尤其在 AUTOCOMMIT=0 模式下）
• InnoDB 的 innodb_lock_wait_timeout 默认仅 50 秒，但锁实际可能挂几小时——超时只是让等待方失败，持有方依然占着资源
• DDL 操作（如 ALTER TABLE）常需获取表级元数据锁（MDL），而长事务会阻止 MDL 升级，导致 DDL 无限等待

长事务拖慢 MVCC 清理，引发磁盘和内存压力

InnoDB 依赖 undo log 实现多版本并发控制（MVCC）。事务越长，其“快照视图”能看到的旧版本数据就越老，意味着更早的 undo log 记录不能被 purge 线程回收。

后果很直接：undo 表空间持续膨胀（ibdata1 或独立 undo_001 文件变大），INFORMATION_SCHEMA.INNODB_TRX 中的 TRX_UNDO_NO 和 TRX_ROWS_MODIFIED 值偏高，SHOW ENGINE INNODB STATUS 的 HISTORY LIST 长度飙升（常 > 10000 就该警觉）。

• HISTORY LIST 过长会显著拖慢查询性能，因为读取每一行都要遍历更多版本链
• 极端情况下 purge 线程追不上 undo 生成速度，触发 Undo log is full 错误，新事务无法分配 undo slot，直接失败
• MySQL 8.0+ 虽支持 innodb_undo_log_truncate，但前提是 HISTORY LIST 长度低于阈值且无长事务拖后腿

主从延迟与 binlog 日志堆积的隐形推手

长事务产生的大量修改，在主库上是一次性提交，但 binlog 是按语句/事务粒度写入的。如果一个事务修改了 50 万行，它对应的 binlog event 就是一个巨型事务日志（可能数 MB），从库 SQL 线程必须串行回放整个事务，无法并行化。

同时，主库的 binlog_cache_size 和 max_binlog_cache_size 若设得太小，长事务还可能触发 Multi-statement transaction required more than 'max_binlog_cache_size' bytes 错误，导致事务直接中断。

• 从库 Seconds_Behind_Master 突然跳涨几十分钟，查 SHOW SLAVE STATUS 发现 SQL_Delay 正在执行一个大事务，基本可锁定问题
• binlog 文件本身不会因长事务变多，但单个文件里有效日志占比下降（空事务、心跳事件混杂），归档和解析效率降低
• 使用 GTID 时，长事务会阻碍 gtid_purged 推进，影响新从库搭建或 binlog 清理策略

如何快速定位和干预正在运行的长事务

别等报警才行动。日常应主动监控 INFORMATION_SCHEMA.INNODB_TRX，重点关注

TRX_STARTED 时间戳和 TRX_STATE 状态。

典型命令：

SELECT TRX_ID, TRX_MYSQL_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;

• 优先 kill 掉 TRX_STATE = 'RUNNING' 但已空闲（无 TRX_QUERY）的连接，这类往往是应用没正确 close connection
• 对仍在执行的长事务，先用 SELECT * FROM performance_schema.threads WHERE THREAD_ID = xxx 查其 client_host 和 program_name，再联系对应服务负责人
• 避免直接 KILL 正在写入的事务——可能触发长 rollback（InnoDB 回滚速度通常远慢于提交），改用 KILL QUERY 中断当前语句，留事务自行决定是否继续

真正棘手的是那些隐藏在连接池背后、自动重连又不重置事务状态的应用逻辑——它们不会出现在活跃会话里，却持续拖着 undo 和锁资源。这种得靠应用层加 SET autocommit = 1 或显式 START TRANSACTION + COMMIT 控制边界。