Undo Log膨胀源于长事务阻塞purge，需在备份前用INNODB_TRX定位trx_state='RUNNING'且trx_query IS NULL的空闲事务，按状态谨慎KILL，并在备份后主动推进purge。
备份时Undo Log膨胀不是备份工具的问题，是长事务在备份窗口内持续运行，导致purge线程无法清理旧版本——必须在mysqldump或mydumper启动前终止所有阻塞事务，否则备份过程本身就会加剧空间失控。
备份前必须查INNODB_TRX定位真凶
别依赖SHOW PROCESSLIST的Time字段，它只反映当前语句执行时长。真正卡住purge的，是那些trx_state = 'RUNNING'且trx_query IS NULL的空闲事务：
- 运行
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)) > 300;，重点关注duration_sec > 300且trx_query IS NULL的记录 -
trx_rows_modified = 0的只读事务也会钉住快照，但危害较小；trx_rows_modified > 1000的写事务才是高危目标 - 用
trx_mysql_thread_id关联information_schema.PROCESSLIST，确认是否为备份客户端自身（如mysqldump连接）或应用残留连接
备份期间禁止盲目KILL，分状态处理
备份过程中若发现长事务，KILL操作必须严格按trx_state判断，否则可能中断备份或拖垮实例：
-
trx_state = 'RUNNING'且trx_query IS NULL：大概率是应用未提交，可安全KILL对应trx_mysql_thread_id -
trx_state = 'LOCK WAIT'：说明被其他事务阻塞，先查INNODB_LOCK_WAITS定位blocking_trx_id，优先干掉上游 -
trx_state = 'ROLLING BACK'：绝对不要KILL，此时InnoDB正在同步回滚，KILL会转为异步，大幅拉长回滚时间并挤占IO - 若
trx_rows_modified > 50000，回滚可能耗时数分钟，KILL前需确认备份是否已加--single-transaction且尚未开始导出关键表
备份后必须手动推进purge，不能等自动回收
即使杀掉长事务，History list length也不会立刻下降。备份完成后的关键动作是主动加速清理：
- 检查进度：
SHOW ENGINE INNODB STATUS\G，关注“PURGE DONE for trx's n:o trx_id看是否在推进 - 临时加大清理力度：
SET GLOBAL innodb_purge_batch_size = 10000;（默认300） - 确认已启用独立undo表空间：
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';，值必须≥2（推荐4） - 开启截断开关：
SET GLOBAL innodb_undo_log_truncate = ON;，再对每个undo表空间执行ALTER UNDO TABLESPACE undo_001 TRUNCATE;
最易被忽略的一点：innodb_undo_log_truncate只在History list length降到阈值以下才生效，而这个阈值取决于innodb_max_undo_log_size（默认1GB）。如果备份期间undo已涨到2GB，即使杀光长事务，purge没把历史记录清到1GB以下，TRUNCATE命令仍会静默失败。必须盯着SHOW ENGINE INNODB STATUS里的数值，等它回落再操作。
