Undo Log膨胀根因是长事务未结束导致purge线程被卡死；所有参数调优仅为缓震，必须先用INFORMATION_SCHEMA.INNODB_TRX定位并终止trx_state='RUNNING'且trx_query IS NULL等阻塞事务。
直接说结论：Undo Log 膨胀不是配置问题，是长事务没结束导致 purge 线程被卡死；所有参数调优都只是缓震器，不杀掉源头事务，调再狠也白搭。
查出真凶：用 INFORMATION_SCHEMA.INNODB_TRX 定位阻塞 purge 的长事务
INFORMATION_SCHEMA.INNODB_TRX 定位阻塞 purge 的长事务INFORMATION_SCHEMA.INNODB_TRX 是唯一能实时看到“谁在钉住 undo”的表。别等磁盘报警，每 5 分钟跑一次：
SELECT trx_id, trx_state, trx_started, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec, trx_rows_modified, SUBSTRING(trx_query, 1, 80) AS trx_query_truncated FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600;
重点关注这三类：
-
trx_state = 'RUNNING'且trx_query IS NULL：应用层开了事务但忘了COMMIT或ROLLBACK，空闲挂起，最危险 -
trx_rows_modified > 10000且duration_sec > 300：大事务正在执行或已卡住，比如批量 UPDATE 没分页 -
trx_state = 'LOCK WAIT'：它被别的事务堵着，得先查INNODB_LOCK_WAITS找 blocking 线程
trx_mysql_thread_id 可直接 JOIN performance_schema.threads 查客户端 IP、用户、数据库名，避免误杀。
KILL 前必须看 trx_state 和 purge 状态
trx_state 和 purge 状态KILL 不是万能解药，乱杀会让回滚更慢、IO 更爆：
-
trx_state = 'RUNNING'且trx_query IS NULL：可安全KILL，99% 是连接池泄漏或 ORM 事务未关闭 -
trx_state = 'LOCK WAIT'：先KILL它的 blocking 事务（查INNODB_LOCK_WAITS），否则重试后还会卡 -
trx_state = 'ROLLING BACK'：别动！此时 InnoDB 正在同步回滚，KILL只会让它从同步变异步，拖垮 purge 线程 - 如果
SHOW ENGINE INNODB STATUS里History list length> 10000，说明 purge 已严重滞后，批量KILL必须加SLEEP(0.2)间隔，否则雪崩
innodb_undo_log_truncate 不是“清空按钮”，它只在条件全满足时才裁剪
innodb_undo_log_truncate 不是“清空按钮”，它只在条件全满足时才裁剪innodb_undo_log_truncate = ON 本身不释放空间，它只是个周期性检查开关（默认每 128 秒触发一次），生效需同时满足：
-
innodb_undo_tablespaces >= 2（推荐设为 4～128），否则逻辑直接跳过 -
History list length < 10000（查SHOW ENGINE INNODB STATUS） - 对应 undo 表空间中没有活跃事务引用的页（即长事务已全部结束）
- undo 文件是独立的（
NAME LIKE 'undo%'且SPACE_TYPE = 'Undo'）
常见误操作：
- MySQL 5.7 且
innodb_file_per_table = OFF：undo 全挤在ibdata1里，truncate完全无效 -
innodb_max_purge_lag = 0：等于关掉节流保护，undo 持续写入直到磁盘满 - 调了
innodb_undo_log_truncate就以为万事大吉，却没查INNODB_TRX里那个运行了 3 小时的空闲事务
innodb_max_purge_lag 是节流阀，不是清洁工
innodb_max_purge_lag 是节流阀，不是清洁工这个参数只在“未 purge undo 记录数”超限时插入微秒级延迟（由 innodb_max_purge_lag_delay 控制），目的是给 purge 线程腾资源，它不清理任何已有 undo，也不影响长事务本身。
典型错误配置：
- 设成
10000：正常批量导入也会被频繁 throttle，TPS 断崖下跌 - 设成
0或10000000：失去保护，undo 持续膨胀 - 单独调它却不配合
innodb_purge_threads（建议设为 4）和innodb_purge_batch_size（建议 500～1000）
推荐组合：
innodb_max_purge_lag = 500000innodb_max_purge_lag_delay = 100000- 同时观察
SHOW ENGINE INNODB STATUS中PURGE DONE是否在缓慢推进
真正起效的前提，永远是：先干掉那个 trx_state = 'RUNNING' 且 trx_query IS NULL 的事务。
最常被忽略的一点：应用层事务生命周期比任何 MySQL 参数都关键。一个没 commit 的 autocommit=0 连接，哪怕只执行了一条 SELECT，也会把 read view 持有数小时——它不写 undo，但会阻止 purge 清理所有旧版本。这类事务在监控里极难识别，却最致命。
