Undo Log回收依赖最老活跃ReadView，Purge线程依据所有活跃事务中最小trx_id清理历史版本；只读长事务虽不产生Undo，但会钉住min_trx_id，阻塞全部后续Undo回收。
Undo Log版本链的回收依赖于最老Read View
Purge线程不是按“事务提交时间”清理Undo，而是看有没有任何活跃事务还需要访问某个历史版本。它会持续抓取全系统当前最老的活跃ReadView，提取其中的min_trx_id（即所有未提交事务中最小的ID），然后只清理那些trx_id严格小于该值的Undo记录。
这意味着：哪怕一个事务只执行了SELECT、没改任何数据、trx_rows_modified = 0，只要它没提交，它的ReadView就一直有效，min_trx_id就被钉住——所有比它新的Undo版本全卡住无法回收。
- REPEATABLE READ下，事务第一次快照读即生成固定
ReadView，后续复用，所以长事务一开就“锚定”清理边界 - READ COMMITTED下每次查询都新建
ReadView，理论上不会长期阻塞Purge，但高并发时仍可能短暂拖慢进度 -
SHOW ENGINE INNODB STATUS\G里PURGE DONE for trx's n:o < XXXXX卡在低值不动，就是min_trx_id被钉死的直接证据
TRX_UNDO_INSERT和TRX_UNDO_MODIFY的回收时机完全不同
Insert类Undo（TRX_UNDO_INSERT_REC）和Update/Delete类Undo（TRX_UNDO_MODIFY_REC、TRX_UNDO_DEL_MARK_REC等）在生命周期上差异极大：
-
TRX_UNDO_INSERT_REC：事务提交后立即释放，不挂入History List，也不参与MVCC，因此几乎不引发膨胀 -
TRX_UNDO_MODIFY_REC：事务提交后必须挂入全局History List链表，等待Purge线程异步扫描清理；它才是Undo表空间膨胀的主力 - 一个改了10万行的长事务，即使只执行一次
COMMIT，也会向History List注入10万个待清理节点
Purge线程真正清理的是Undo Page，不是单条Undo Record
InnoDB的Purge不是逐条删除Undo日志，而是以Page为单位批量回收物理页面。每个Undo Log Segment由多个连续Page组成，Purge线程在确认整个Segment已无引用后，才会将其标记为可截断（truncate）。
这就解释了为什么MySQL 8.0引入独立Undo表空间后才支持在线回收：只有把Undo从ibdata1中拆出来，才能对单个undo_001文件执行ALTER UNDO TABLESPACE undo_001 INACTIVE → 等待状态变为INACTIVE → DROP。而5.7及之前，ibdata1混着数据字典、双写缓冲等，根本无法收缩。
- 触发截断的前提是：目标Undo表空间内所有Undo Segment都已释放，且状态为
INACTIVE -
innodb_undo_log_truncate默认开启，但仅当表空间大小超过innodb_max_undo_log_size（默认1G）时才尝试截断 - 如果
HISTORY LIST LENGTH持续> 5000，说明Purge推进停滞，截断永远不会触发
杀错事务会让Purge更慢，而不是更快
盲目KILL可能让问题恶化，关键要看trx_state：
-
trx_state = 'RUNNING'且trx_query IS NULL：极大概率是应用崩溃后连接未关闭，可安全KILL -
trx_state = 'LOCK WAIT'：它正被别的事务堵住，先查INNODB_LOCK_WAITS找出blocking_trx_id，干掉上游事务 -
trx_state = 'ROLLING BACK'：千万别KILL，中断回滚会导致InnoDB转为后台异步清理，IO压力陡增，反而拖垮Purge
真正卡住Purge的，往往不是正在狂写的大事务，而是那个空闲了20分钟、trx_rows_modified = 0、却始终没COMMIT或ROLLBACK的只读连接——它不产生Undo，但死死攥着最老ReadView。这点最容易被忽略。
