MySQL自动维护Undo Log版本链：InnoDB在UPDATE/DELETE时将旧版本写入undo log并用roll_ptr串联成链，由内核管理、用户不可干预，服务于MVCC和崩溃恢复，生命周期受事务状态与purge线程控制。
Undo Log版本链是怎么被MySQL自动维护的
InnoDB在事务修改行记录时，不是直接覆盖原数据，而是把旧版本写进undo log，并用roll_ptr字段把新旧版本串成链表——这就是版本链。每次UPDATE或DELETE都会生成新节点，INSERT不产生undo（除非后续被回滚）。版本链头是最新值，尾是最早可读快照。
关键点在于：这个链完全由InnoDB内核管理，用户不能手动增删节点，也不能指定某条记录保留几个历史版本。它只服务于MVCC和崩溃恢复，生命周期由事务状态和purge线程控制。
-
READ COMMITTED隔离级别下，每次SELECT都重新构建一致性视图，版本链上“可见”的节点可能变短 -
REPEATABLE READ下，事务第一次SELECT时创建快照，后续查询复用，版本链中“不可见”但未被purge的老版本会一直挂着 - 长事务不提交，会阻塞purge线程清理undo页，导致
undo log持续膨胀、ibdata1文件增长
如何查当前事务能看到哪些undo版本
没有SQL能直接列出某行的完整版本链，但可以通过information_schema.INNODB_TRX和information_schema.INNODB_LOCK_WAITS间接观察活跃事务对undo的占用情况。更实用的是用SHOW ENGINE INNODB STATUS里的HISTORY LIST长度判断undo积压程度——数值越大，说明有越多旧版本没被清理。
-
HISTORY LIST长度超过10万通常意味着存在未提交的长事务或purge跟不上写入速度 - 配合
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(now(), trx_started)) > 60找出运行超1分钟的事务 - 注意：
innodb_max_purge_lag参数仅影响DML速率，不主动触发purge，别指望靠它“自动清干净”
为什么REPEATABLE READ下幻读没消失，但快照读不查新插入行
因为MVCC快照读（普通SELECT）依赖的是事务启动时构造的read view，它只决定“哪些undo版本可见”，不锁住间隙。新插入的行如果trx_id大于当前read view的up_limit_id，就直接不可见——哪怕这行物理上已落盘。
- 所谓“快照”不是复制一份数据，而是用
read view+ 版本链做逻辑过滤 - 当前事务自己插入/修改的行，无论是否提交，其
trx_id一定在read view的low_limit_id范围内，所以自己总能看见 - 如果需要真正阻止幻读，必须用
SELECT ... FOR UPDATE或INSERT ... SELECT配合唯一约束，而不是依赖快照读
undo表空间满了或purge卡住时的典型错误
最常见报错是ERROR 1783 (HY000): Cannot execute statement in a READ ONLY transaction（实际是undo满导致无法分配新rollback segment），或者写入突然变慢、SHOW PROCESSLIST里大量updating状态卡住。这时innodb_undo_log_truncate未必起效——它只在满足innodb_undo_tablespaces > 2且有空闲undo表空间时才触发轮转。
- 检查
innodb_undo_directory磁盘剩余空间，比看ibdata1大小更直接 -
SET GLOBAL innodb_purge_rseg_truncate_frequency = 32可加快undo段回收节奏（默认128），但治标不治本 - 真正有效的做法是杀掉滞留事务：
KILL [trx_mysql_thread_id]，再等purge线程追平，而不是重启MySQL——重启后purge仍要重放一遍
事务一开就忘关，undo链就停不下来。最麻烦的不是查不到历史版本，而是别人查不到你该释放却没释放的版本。
