undo log无法自动收缩的根本原因是innodb_undo_log_truncate未真正生效，必须满足独立undo表空间（innodb_undo_tablespaces≥2）、purge完成、无长事务等全部前提，否则仅调参无效；truncate后文件大小不变是innodb设计使然，磁盘空间释放需optimize tablespace（8.0.30+）或停库重建。
Undo Log 无法自动收缩，基本可以断定是 innodb_undo_log_truncate 没真正生效——不是参数没开，而是底层前提全不满足。直接调参、重启、改阈值都没用，必须按拓扑结构和运行状态逐项验证。
查清楚你有没有独立 undo 表空间
这是最常被跳过的一步。很多 DBA 看到 innodb_undo_log_truncate = ON 就以为万事大吉，但只要 innodb_undo_tablespaces 返回 0 或空，这个开关就完全不参与逻辑。
- 执行
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';，值必须 ≥ 2（推荐设为 4） - 如果返回 0 或空，说明你的 undo 还在
ibdata1里，innodb_undo_log_truncate彻底无效 - 此时别折腾配置，停库重建才是唯一路径：备份 → 修改
my.cnf→ 删除旧ibdata1和undo*文件 → 重启生成新表空间
确认 purge 是否真被长事务卡死
即使有独立 undo 表空间，innodb_undo_log_truncate 也只在 purge 完成后才触发。而 purge 卡住的元凶，99% 是那些 trx_state = 'RUNNING' 且 trx_query IS NULL 的“幽灵事务”。
- 运行
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_rows_modified > 0、且trx_query为空的记录 - 用
trx_mysql_thread_id关联information_schema.PROCESSLIST，确认是不是应用连接异常挂起（比如 Python 进程崩溃但 TCP 连接未断） - 这类事务必须先
KILL，否则无论怎么调innodb_purge_batch_size或innodb_max_undo_log_size都是白忙
手动触发 truncate 的真实操作路径
所谓“手动触发”，本质是临时制造条件让 InnoDB 在下一轮检查中立刻满足截断要求。它不是命令式操作，而是策略性诱导。
- 先查当前阈值：
SELECT @@innodb_max_undo_log_size;（默认 1GB） - 临时压低：
SET GLOBAL innodb_max_undo_log_size = 10485760;（10MB） - 等待最多 128 秒（
innodb_purge_rseg_truncate_frequency默认值），观察错误日志是否出现[Note] InnoDB: Truncating tablespace ./undo/undo_001 - 成功后立即恢复原值：
SET GLOBAL innodb_max_undo_log_size = 1073741824; - 注意：
ALTER TABLESPACE undo001 ENGINE=InnoDB完全无效，别再试了
为什么 du -h 看不到文件变小？
这是最易引发误判的设计事实：InnoDB 的 truncate 只重置内部 LSN 和页位图，**不调用系统 ftruncate()，也不删文件**。所以 ls -lh undo001 大小纹丝不动。
- 文件内容被逻辑清空，新事务写入从头开始，但磁盘空间仍被旧文件占据
- 真正释放磁盘空间只有两条路：
OPTIMIZE TABLESPACE undo001（MySQL 8.0.30+，仅优化碎片，不缩文件）或停库后删除 + 重启重建 - 生产环境若急需腾空间，只能走重建流程——这意味着必须提前规划维护窗口
真正卡住收缩的，从来不是参数开关，而是那个没提交的事务、那个没关闭的连接、那个忘了设超时的 ORM session。所有配置都只是在给应用层漏洞兜底，而不是替代它。
