必须先杀掉最老的trx_state='RUNNING'且trx_query IS NULL的事务，否则所有调参、截断、purge加速均无效；需用INNODB_TRX按trx_started排序定位，并依trx_state分情况安全KILL，再配合purge参数调优与undo表空间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';，值必须 ≥ 4（推荐） - 开启自动截断：
SET GLOBAL innodb_undo_log_truncate = ON;，再执行：ALTER UNDO TABLESPACE undo_001 SET INACTIVE→ 等HISTORY LIST LENGTH显著回落 →ALTER UNDO TABLESPACE undo_001 TRUNCATE
最容易被忽略的是：MySQL 8.0 要求至少保留 2 个 active 的 undo 表空间才能 TRUNCATE，新增第 3 个后再设旧的为 inactive，跳步必失败。
