长事务导致Undo Log无法清理，因其创建的Read View长期有效并钉住min_trx_id，使purge线程无法回收其依赖的历史版本；无论只读或写事务，在REPEATABLE READ下均会冻结可见性边界，造成HISTORY LIST LENGTH持续升高、undo表空间膨胀及purge停滞。
长事务导致Undo Log无法清理，Read View会卡住旧版本
长事务不提交，意味着它创建的 Read View 一直有效，而这个视图里的 m_ids（活跃事务ID列表）会持续包含该长事务ID。InnoDB的purge线程判断一个undo log版本能否清理，关键看是否还有任何 Read View 需要它——只要有一个未提交的长事务在运行，哪怕其他事务早已结束，它所依赖的最老版本链节点就始终不能被回收。
常见错误现象：innodb_undo_log_truncate 失效、undo tablespace 持续膨胀、SHOW ENGINE INNODB STATUS 中看到 Purge done for trx's n:o < XXXXX 卡在某个低值不动。
- 长事务启动后，第一次快照读即生成固定
Read View，后续所有查询都复用它，不会更新min_trx_id或m_ids -
max_trx_id仍随新事务递增，但min_trx_id被钉死在长事务ID附近，导致大量旧版本“可见性判断”结果为“需保留” - 即使长事务只执行
SELECT不修改数据，它本身的存在就阻止了 purge 清理——因为它的Read View理论上仍可能需要访问那些旧版本
RC和RR隔离级别下，长事务对Read View的生成时机影响完全不同
隔离级别直接决定 Read View 是“语句级”还是“事务级”生成，这在长事务场景中差异巨大。
在 READ COMMITTED 下，每次 SELECT 都新建 Read View，所以长事务内反复查询，看到的数据会随其他事务提交而变化；但在 REPEATABLE READ 下，仅事务第一个快照读时生成 Read View，之后全部复用——这就让长事务成了“时间锚点”，把整个版本链的存活窗口强行拉长。
-
READ COMMITTED：长事务本身不阻塞 purge，但频繁查询会不断生成新Read View，若恰逢高并发写入，仍可能短暂拖慢 purge 进度 -
REPEATABLE READ：长事务一开启就锁定Read View，min_trx_id不再推进，undo log 版本链“冻结”在事务启动时刻的可见性边界 - 注意：
SELECT ... FOR UPDATE或UPDATE属于当前读，不走Read View，但会触发行锁并可能延长事务持有时间，间接加剧问题
DB_TRX_ID 和 DB_ROLL_PTR 如何协作定位“该读哪个版本”
版本链遍历不是盲目倒查，而是靠每条记录的 DB_TRX_ID 与当前事务的 Read View 四个字段做精确比对。核心逻辑是：从最新版本开始，按 DB_ROLL_PTR 往前跳，遇到第一个满足可见性规则的版本就停。
可见性规则实际是三段式判断：DB_TRX_ID < min_trx_id → 已提交，可见；DB_TRX_ID == creator_trx_id → 自己改的，可见；DB_TRX_ID ∈ m_ids → 其他未提交事务改的，不可见；其余情况一律不可见。
- 长事务的
creator_trx_id小，min_trx_id也小，导致大量旧版本落入“DB_TRX_ID < min_trx_id”区间，被判定为可读——这正是它能重复读到相同结果的原因 -
DB_ROLL_PTR是单向指针，只能向前（更旧）跳，不能反向；因此版本链越长，最坏情况下需要遍历更多节点才能找到可见版本 - 如果长事务持续数小时，而业务又高频更新同一行，版本链可能长达数百节点，单次查询延迟上升虽不明显，但整体 undo 空间压力陡增
如何快速识别和缓解长事务对MVCC的实质性影响
不能只盯着 information_schema.INNODB_TRX 查 TRX_STARTED，得结合 purge 进度和 undo 空间使用率交叉验证。
关键指标：SELECT @@innodb_purge_lsn 对比 SELECT MAX(TRX_ID) FROM information_schema.INNODB_TRX；差值过大说明 purge 落后严重；同时检查 innodb_undo_tablespaces 文件大小是否持续增长。
- 临时缓解：手动执行
SET GLOBAL innodb_max_purge_lag = 1000000（慎用，可能拖慢写入） - 根治方法：监控
TRX_STATE = 'RUNNING'且TRX_STARTED超过 60 秒的事务，通过KILL或应用层超时中断 - 开发侧规避：避免在事务里嵌套耗时操作（如远程HTTP调用、大文件处理），把长事务拆成多个短事务+补偿逻辑
真正容易被忽略的点是：即使长事务只做纯读，它也会让 Read View 长期驻留内存，并持续阻断 purge——这不是 bug，是 MVCC 设计使然。优化必须从“事务生命周期管理”切入，而不是只调参数。
