长事务会导致锁阻塞、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 控制边界。
