必须先杀掉trx_state='RUNNING'且trx_query IS NULL的事务，否则所有调参和截断操作均无效；需用INNODB_TRX定位超600秒的可疑事务，按状态分类KILL，并在杀完后加大purge参数、启用独立undo表空间并分步执行TRUNCATE。
必须先杀掉 trx_state = 'RUNNING' 且 trx_query IS NULL 的事务，否则所有参数调整、ALTER UNDO TABLESPACE TRUNCATE 或加大 innodb_purge_batch_size 都无效——Undo Log 暴涨是 purge 线程被卡死的表象，不是磁盘配额问题。
怎么快速定位真正卡住 purge 的长事务
别信 SHOW PROCESSLIST 的 Time 字段，它只反映当前语句执行时长，和事务开启时间无关。真正钉住 undo 的，是那些早已空闲却没提交的连接。
- 运行这条语句查最老的可疑事务：
SELECT trx_id, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec, trx_state, trx_rows_modified, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600 ORDER BY trx_started LIMIT 5 - 重点关注：
duration_sec > 600、trx_state = 'RUNNING'、且trx_query IS NULL的记录——99% 是应用漏了COMMIT或连接池未close -
trx_rows_modified > 10000且持续时间长的写事务，必须立刻干预；只读事务虽不新增 undo，但也会阻塞 purge - 用
trx_mysql_thread_id关联information_schema.PROCESSLIST，查HOST、USER、COMMAND和INFO，确认是否为异常挂起（比如 Python 进程崩溃但连接残留）
KILL 前必须按 trx_state 分类处理
盲目 KILL 可能让实例雪崩，不同状态要区别对待：
-
trx_state = 'RUNNING'且trx_query IS NULL：可安全KILL，大概率是 ORM 事务未关闭或 HTTP 调用后忘记commit -
trx_state = 'LOCK WAIT'：说明它被别的事务堵住了，先查INNODB_LOCK_WAITS找出blocking_trx_id，优先干掉上游事务 -
trx_state = 'ROLLING BACK'：别动，此时KILL会让回滚从同步变异步，耗时翻倍、IO 更爆，甚至拖垮 purge 线程 - 若
trx_rows_modified > 100000，回滚可能持续数分钟，KILL前务必评估业务影响 - 当
History list length > 10000，批量KILL必须加SLEEP(0.2)间隔执行，避免 IO 冲突
杀完之后如何让 History list length 真正回落
杀掉源头事务后，History list length 不会立刻下降，需主动助推 purge 并触发截断：
- 先检查 purge 是否在推进：
SHOW ENGINE INNODB STATUS\G，看 “PURGE DONE for trx's n:o” 后的数字是否持续增长 - 临时加大清理能力：
SET GLOBAL innodb_purge_batch_size = 10000（默认 300） - 确保已启用独立 undo 表空间：
SHOW VARIABLES LIKE 'innodb_undo_tablespaces'，值必须 ≥ 4（仅 ≥ 2 不够轮换） - 开启自动截断：
SET GLOBAL innodb_undo_log_truncate = ON，再执行ALTER UNDO TABLESPACE undo_001 SET INACTIVE→ 等History list length显著回落后再ALTER UNDO TABLESPACE undo_001 TRUNCATE
最容易被忽略的是：ALTER UNDO TABLESPACE ... TRUNCATE 失败往往不是因为权限或语法，而是 purge 还没推进到对应段，或者 undo 表空间数量不够轮换——必须先新增第 3 个 undo 表空间，再设旧的为 inactive，顺序错一步就卡死。
