如何处理MySQL升级后由于Undo Log自动回收机制变化导致的磁盘空间波动？-mysql教程-PHP中文网

mysql升级后undo log磁盘空间波动，主因是新版本更严格执行purge和truncate，残留长事务或xa事务会卡住history list导致空间涨得快、缩得慢；必须实锤确认独立undo表空间已启用、purge真在推进、且满足inactive/ready/无依赖三条件后，truncate才生效，物理文件大小不变属正常设计。

如何处理mysql升级后由于undo log自动回收机制变化导致的磁盘空间波动？

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：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

执行 XA RECOVER;，检查是否有未完成的 XA 事务；若有，用 XA ROLLBACK 清理
查 SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_query IS NULL AND trx_started ，重点盯住 <code>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 应接近 0；否则 purge 没清完旧段
三者全满足后，再等最多 128 秒（innodb_purge_rseg_truncate_frequency 默认值），日志中出现 [Note] InnoDB: Truncating tablespace ./undo/undo_001 才算真正启动