必须先杀掉最老的 trx_state = 'RUNNING' 且 trx_query IS NULL 的事务，否则调参、截断、加大 purge 全部无效；它源于事务生命周期失控，需用 INNODB_TRX 按 trx_started 排序定位，结合 PROCESSLIST 判断异常连接，再依 trx_state 分类处理，最后在满足条件时手动触发 TRUNCATE。
必须先杀掉最老的 trx_state = 'RUNNING' 且 trx_query IS NULL 的事务，否则所有后续操作（调参、截断、加大 purge）全部无效。这不是配置问题，是事务生命周期失控的直接表现。
怎么快速定位真正卡住 purge 的长事务
别信 SHOW PROCESSLIST 的 Time 字段——它只反映当前语句执行时长，和 undo 钉住无关。真正拖垮 purge 的，是那些早已空闲、没提交、但还挂着 ReadView 的连接。
- 运行这条语句查最老活跃事务：
SELECT trx_id, trx_started, trx_state, trx_rows_modified, trx_mysql_thread_id FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5; - 重点关注
trx_started超过 600 秒、trx_state = 'RUNNING'、且trx_query IS NULL的记录（常见于 Python 进程崩溃但连接未 close，或 ORM 忘关 transaction） - 用
trx_mysql_thread_id关联information_schema.PROCESSLIST，确认HOST、USER、COMMAND和INFO，判断是否为异常挂起的应用连接 -
trx_rows_modified = 0的只读事务也会阻塞 purge，但危害小；trx_rows_modified > 10000且长时间未提交的写事务必须立刻干预
kill 前必须分状态处理，否则可能更糟
盲目 KILL 可能让回滚变慢、IO 更满，甚至拖垮 purge 线程。不同 trx_state 要区别对待：
-
trx_state = 'RUNNING'且trx_query IS NULL：极大概率是应用漏了COMMIT或ROLLBACK，可安全KILL对应thread_id -
trx_state = 'LOCK WAIT'：它被别的事务堵住了，先查INNODB_LOCK_WAITS找出blocking_trx_id，优先干掉上游事务 -
trx_state = 'ROLLING BACK'：别动，此时KILL只会让回滚从同步变异步，加剧 IO 压力、延长 purge 延迟 - 若
trx_rows_modified > 100000，回滚可能耗时数分钟，KILL前务必评估业务影响
清理后如何让 undo 空间真正回落
杀掉源头事务后，HISTORY LIST LENGTH 不会立刻下降，需手动助推 purge，并满足严格条件才能触发 TRUNCATE：
- 先检查 purge 进度：
SHOW ENGINE INNODB STATUS\G，关注 “PURGE DONE for trx's n:o < XXX” 行，确认是否在推进 - 临时加大清理力度：
SET GLOBAL innodb_purge_batch_size = 10000;（默认 300） - 确认已启用独立 undo 表空间：
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';，值必须 ≥ 2（推荐设为 4） - 开启自动截断：
SET GLOBAL innodb_undo_log_truncate = ON;，但注意：它只在HISTORY LIST LENGTH < 10000且对应 undo 表空间无活跃事务引用时才生效 - 执行
ALTER UNDO TABLESPACE undo_001 TRUNCATE;前，必须确保已新增第 3 个 undo 表空间、旧表空间已SET INACTIVE，否则报错ERROR 3655 (HY000): Cannot set innodb_undo_001 inactive since there would be less than 2 undo tablespaces left active
整个流程里最容易被忽略的点是：TRUNCATE 不是“一键清空”，它依赖 purge 先完成清理；而 purge 能否跟上，又完全取决于有没有残留的 trx_state = 'RUNNING' 且 trx_query IS NULL 的事务。只要漏掉一个，后续所有操作都只是原地打转。
