长事务会导致Undo Log严重堆积，表现为history_list_length持续上涨至数百甚至上万，ibdata1或undo_001文件缓慢膨胀，磁盘每日增长数GB，SELECT COUNT(*)变慢，innodb_undo_log_truncate失效，且REPEATABLE READ下压力显著高于READ COMMITTED。
长事务会让Undo Log堆积到什么程度
Undo Log不是“用完就扔”，而是要等所有可能用到它的事务都结束才能清理。一个未提交的长事务，会把整个MVCC快照链钉住——哪怕它只改了一行，history_list_length也会持续上涨，SHOW ENGINE INNODB STATUS里能看到这个值卡在几百甚至上万。
常见现象包括：
-
ibdata1或独立undo_001文件缓慢但稳定地膨胀，磁盘使用率每天涨几个GB - 简单
SELECT COUNT(*)变慢，尤其没索引的大表，因为要遍历更长的版本链 -
innodb_undo_log_truncate=ON不生效——truncate动作被阻塞，因purge线程无法推进
根本原因不是写得多，而是“旧版本不能丢”。REPEATABLE READ隔离级别下，这个压力比READ COMMITTED高得多。
为什么“只读事务”也会锁死DDL
哪怕你只执行了BEGIN; SELECT * FROM t;就挂在那里，InnoDB仍会给表加MDL_SHARED_READ锁。这个锁不会随语句结束释放，而要等到事务提交或回滚。
后果很直接：
-
ALTER TABLE t ADD COLUMN x INT;会卡在Waiting for table metadata lock，且不受innodb_lock_wait_timeout控制 - 运维查
SHOW PROCESSLIST看到State是Sleep、Command是Sleep、Time很大，却误以为只是空闲连接 - trx_query为空、trx_state为
RUNNING，才是典型长事务空闲挂起信号
这种锁不占行锁资源，但能拦住所有DDL，而且排查时容易忽略。
行锁真的会“焊死”在一行上吗
会。InnoDB的X锁和next-key锁生命周期 = 事务生命周期。不是语句执行完就放，而是COMMIT/ROLLBACK才释放。
比如这条语句：
BEGIN; UPDATE orders SET status = 'shipped' WHERE order_id = 12345; -- 忘记COMMIT
结果就是：
- 其他事务对
order_id = 12345做UPDATE或SELECT FOR UPDATE全被堵住，状态变成Locked或Updating - 如果
orders.order_id是主键，那只是单行X锁；但如果WHERE条件走的是非唯一索引，next-key锁可能锁住整个间隙，连order_id = 12344或12346都动不了 -
TRX_ROWS_LOCKED字段在INNODB_TRX里可能显示几万，看起来像锁了整张表，实际只是锁范围大
拆小事务不能靠“减少SQL条数”，关键是要缩短锁持有时间。批量更新按1000条一批、每批COMMIT，比包成一个事务快十倍还少锁争用。
连接池耗尽往往比锁表更难定位
每个长事务独占一个数据库连接，且连接不会归还给池。HikariCP设了maximumPoolSize=20，20个长事务跑满，新请求连getConnection()都超时。
这时候你看到的现象是：
- 应用层报500、熔断、HTTP超时，而不是数据库报错
-
SHOW PROCESSLIST里只有20个Sleep连接，看起来“一切正常” - 监控里TPS骤降、连接等待数飙升，但慢查询日志一片空白
真正麻烦的是：它不像锁表那样有明显阻塞链路，你得从应用日志反推哪段代码开了事务没关，或者从INNODB_TRX里查TRX_STARTED最早那批事务对应的应用IP和线程名。
Undo Log积压和锁占用都不是孤立问题，它们共享同一个根因：事务没及时结束。监控TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60只是起点，关键是让业务代码在明确边界处COMMIT或ROLLBACK，而不是依赖框架自动收尾。
