17370845950

最老活跃事务决定undo日志回收边界，因其未提交前需依赖undo提供一致性读视图；InnoDB通过trx_sys->min_trx_id动态维护该值，长事务、空闲事务、XA PREPARE及一致性读事务均会阻塞其推进。

Undo日志回收时，判断“最老活跃事务”（oldest active transaction）是关键。它决定了哪些undo日志段仍可能被需要，不能被清理；只有早于该事务开始时间的undo记录，才可安全回收。

为什么是最老事务，而不是已提交事务？

因为InnoDB的MVCC机制依赖undo日志为**仍在运行的事务**提供一致性读视图。即使一个事务只读不写，只要它尚未提交，就可能需要访问过去某个时间点的数据版本——这些版本就保存在undo日志中。因此，系统必须保留所有**晚于该事务启动时刻**产生的undo记录。

注意：已提交事务的undo日志不一定立刻可删，还要看是否有其他长事务或一致性读需求依赖它。

如何确定当前最老活跃事务？

InnoDB内部维护一个全局变量 trx_sys->min_trx_id（在早期版本中也称 min_active_trx_id），它代表当前所有活跃事务中最小的事务ID（即最早开始的未提交事务）。这个值会随新事务开启、旧事务提交/回滚动态更新。

• 事务开启时，分配递增的trx_id，并参与min_trx_id的竞争更新
• 事务提交或回滚后，若其trx_id等于当前min_trx_id，则InnoDB会遍历活跃事务链表重新计算新的最小值
• 该值可通过 SHOW ENGINE INNODB STATUS 中的 HISTORY LIST 和 TRANSACTIONS 部分间接观察

常见影响最老事务判定的因素

以下情况会导致min_trx_id长期不推进，阻塞undo回收：

• 长事务未提交：比如一个SELECT执行了10分钟且未结束，它会把min_trx_id卡在启动时刻
• 显式开启事务后空闲等待：BEGIN后不执行SQL也不COMMIT，连接保持打开状态
• XA PREPARE状态事务：处于两阶段提交的prepared状态，也算活跃事务
• 只读事务启用一致性读：如使用 START TRANSACTION WITH CONSISTENT SNAPSHOT，也会纳入活跃事务集合

运维建议：主动识别和干预

定期检查是否存在异常长事务：

• 查活跃事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60;
• 查历史列表长度：SHOW ENGINE INNODB STATUS 中关注 HISTORY LIST 行，持续增长说明undo积压
• 设置超时自动断开：wait_timeout 和 interactive_timeout 防止连接空闲挂起事务
• 应用层确保事务粒度合理，避免BEGIN后长时间无操作