History list length持续高于10000且不回落是undo堆积的核心指标，表明purge被卡死；必须先定位并终止trx_state='RUNNING'且trx_query IS NULL的长事务，再调大innodb_purge_batch_size助推清理。
查 History list length 是否卡在高位
这个值才是 undo 是否真堆积的核心指标，不是看文件大小，也不是看有没有 undo 文件。执行 SHOW ENGINE INNODB STATUS\G，在输出里找 History list length —— 如果稳定在 5000 以上、尤其长期高于 100000，基本可断定 purge 被卡死。
它不回落，说明旧版本记录一直没法清理，后续所有事务产生的 undo 都只能追加写入。此时即使 innodb_undo_log_truncate = ON 也毫无作用，因为截断的前提是 purge 已推进到对应位置。
常见干扰项：
-
ls -lh /var/lib/mysql/undo*显示几十 GB ≠ 一定有问题，可能只是历史峰值未释放 -
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_history_list_length'返回 0 或极低值，但磁盘仍在涨 → 很可能是 binlog 或 ibdata1 在撑大，不是 undo
定位真正卡住 purge 的长事务
别信 SHOW PROCESSLIST 的 Time 字段，它只反映当前语句执行时长。真正钉死 purge 的，是那个最早启动却没提交的空闲连接。
必须查 INNODB_TRX 表，用这个语句快速筛出风险点：
SELECT trx_id, trx_state, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec, trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600;
重点关注三类记录：
-
trx_state = 'RUNNING'且trx_query IS NULL：99% 是应用漏了COMMIT或连接池未 close，可优先 KILL -
trx_rows_modified > 10000且duration_sec > 300：大写事务已卡住，需立刻干预 -
trx_state = 'LOCK WAIT'：它被别的事务堵住了，得先查INNODB_LOCK_WAITS找出 blocking_trx_id，干掉上游
确认 undo 表空间是否真独立且可轮换
MySQL 8.0 默认启用独立 undo，但升级或迁移后容易失效。先验证两件事：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
第一，查配置：SHOW VARIABLES LIKE 'innodb_undo_tablespaces'; —— 返回值必须 ≥ 2。若为 0 或 1，说明 undo 还挤在 ibdata1 里，ALTER UNDO TABLESPACE TRUNCATE 会直接报错 ERROR 3655 (HY000)。
第二，查物理文件：ls -lh /var/lib/mysql/undo* —— 应该能看到 undo_001.ibu、undo_002.ibu 等，后缀必须是 .ibu；如果只有 ibdata1，那所谓“undo 涨”其实是系统表空间问题，收缩逻辑完全不同。
注意：innodb_undo_log_truncate = ON 默认开启，但仅当满足轮换条件（≥2 个 active undo 表空间 + purge 跟上）才会触发。光开参数没用。
杀事务后 History list length 不降怎么办
KILL 掉源头事务后，History list length 不会立刻下降，这是正常现象。purge 是异步后台线程，需要时间推进。
先确认 purge 是否真在跑：SHOW ENGINE INNODB STATUS\G 里找 PURGE DONE for trx's n:o 后的数字是否持续增长。如果不涨，说明 purge 线程本身卡住或被抑制。
可临时助推一把：
-
SET GLOBAL innodb_purge_batch_size = 10000;（默认 300，加大能加快清理节奏） -
SET GLOBAL innodb_purge_rseg_truncate_frequency = 16;（默认 128，缩短截断检查间隔） - 确保
innodb_undo_tablespaces ≥ 4，留足轮换余量，避免设 inactive 时只剩 1 个 active 表空间而失败
真正难的不是查和杀，而是判断哪个事务该杀、哪个不能动、杀完之后怎么让 purge 真正跟上——这些动作之间有强依赖，顺序错一步，整个流程就卡死。
