MySQL升级后undo log磁盘空间波动，主因是新版本更严格执行purge和truncate，残留长事务或XA事务会卡住HISTORY LIST导致空间涨得快、缩得慢；必须实锤确认独立undo表空间已启用、purge真在推进、且满足inactive/ready/无依赖三条件后，truncate才生效，物理文件大小不变属正常设计。
MySQL 升级后 undo log 磁盘空间波动，大概率不是“回收机制变强了”，而是旧版本容忍长事务、新版本更严格地执行 purge 和 truncate —— 一旦有残留事务卡住 HISTORY LIST，空间就涨得快、缩得慢，甚至卡死不缩。必须按新版本行为重新校准监控和处置节奏。
查清楚当前 MySQL 版本是否启用真正的独立 undo 表空间
8.0+ 默认仍可能把 undo 放在 ibdata1 里，innodb_undo_log_truncate = ON 彻底无效。别信配置开了就行，得实锤：
- 运行
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';，值必须 ≥ 2（推荐设为 4） - 查
SELECT NAME, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE SPACE_TYPE = 'Undo';，确认至少看到undo_001、undo_002这类独立文件 - 如果只返回空或
ibdata1，说明升级没重建 undo 结构，TRUNCATE永远不会触发，必须停库迁移
确认 purge 是否真在推进，而不是被升级后残留的 XA 或只读事务卡住
MySQL 8.0.21+ 对 XA PREPARED 事务更敏感：一个残留的 XA PREPARE 就会让整个 undo 表空间 TRUNCATE_STATUS 卡在 not_truncate_ready。不能只看 INNODB_TRX：
- 执行
XA RECOVER;，检查是否有未完成的 XA 事务；若有，用XA ROLLBACK清理 - 查
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_query IS NULL AND trx_started < DATE_SUB(NOW(), INTERVAL 10 MINUTE);，重点盯住trx_rows_modified = 0的只读连接——它们在旧版影响小，新版会拖慢 purge 频率 - 观察
SHOW ENGINE INNODB STATUS\G中的PURGE PROCESSED行，对比HISTORY LIST LENGTH是否在下降；不降= purge 被堵死
手动触发 truncate 前必须满足三个状态条件
升级后自动截断失败，90% 是因为只改了参数，没等状态就绪。InnoDB 不接受“命令式”截断，只响应“条件就绪”：
-
ALTER UNDO TABLESPACE undo_001 SET INACTIVE;成功后，查INFORMATION_SCHEMA.INNODB_TABLESPACES中STATE必须变为inactive（不是empty） -
SELECT TRUNCATE_STATUS FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME = 'undo_001';必须返回truncate_ready（不是not_truncate_ready） -
SELECT COUNT(*) FROM information_schema.INNODB_TRX WHERE trx_started < (SELECT MIN(trx_started) FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING');应接近 0；否则 purge 没清完旧段 - 三者全满足后，再等最多 128 秒（
innodb_purge_rseg_truncate_frequency默认值），日志中出现[Note] InnoDB: Truncating tablespace ./undo/undo_001才算真正启动
收缩后文件大小不变？这不是 bug，是 InnoDB 的设计事实
即使 TRUNCATE 成功、STATE 变成 empty，物理文件大小也不变——这是 InnoDB 的保留策略，避免频繁分配/释放磁盘块。线上常因此误判“没生效”：
- 空间是否真正释放，看
df -h或du -sh /var/lib/mysql/undo/*，不是看ls -lh - MySQL 8.0.30+ 提供
OPTIMIZE TABLESPACE undo_001;主动归还磁盘空间，但会锁表、需业务低峰执行 - 低于 8.0.30 的版本，唯一彻底释放方式是：停库 → 备份 → 删除旧 undo 文件 → 重启生成新表空间 → 导入数据
- 别碰
rm undo_001.ibd，实例启动直接报错Tablespace not found
最易被忽略的一点：升级后默认 innodb_purge_threads = 1，而高并发写场景 purge 容易滞后。若 HISTORY LIST 持续 > 5000，应设为 4 并观察 purge_trx_count 下降速度——这不是调优，是补上旧版本隐式做的事。
