MySQL的undo表空间文件无法在线shrink，唯一安全回收磁盘空间的方式是停机重建实例或通过新增+停用+删除undo表空间实现“轮转式替换”。
undo tablespace 文件无法直接 shrink
MySQL 的 undo tablespace 文件（如 undo_001）一旦增长，InnoDB 不支持在线 shrink 或 truncate。你执行 ALTER TABLESPACE ... DROP DATAFILE 也没用——除非满足极严格的条件：该 undo 表空间**完全空闲且未被任何事务引用**，而现实中几乎不可能。
常见错误现象：ALTER TABLESPACE undo_001 DROP DATAFILE 报错 ERROR 3125 (HY000): Cannot drop the last datafile of an undo tablespace，或提示“tablespace is in use”。
- 只有当
innodb_undo_tablespaces > 2且你停用其中某个（设为INACTIVE）后，才可能在重启后删掉对应文件——但这不是“缩减”，是“换掉” -
innodb_undo_log_truncate = ON只控制 undo 日志是否可轮转清理，不释放磁盘空间；它只对ACTIVE状态之外的 undo 表空间生效 - 真正释放空间的唯一路径：停机 + 手动替换 + 重放 binlog（高风险）或重建实例
如何安全地轮转并回收 undo 空间
核心思路不是“缩”，而是“换”：让新事务写入新的 undo 表空间，旧的自然归档、停用、删除。
使用场景：长期运行的 OLTP 库，undo 占用持续增长，但不能停机太久。
- 确认当前配置：
SELECT @@innodb_undo_tablespaces, @@innodb_undo_log_truncate, @@innodb_max_undo_log_size - 确保
innodb_undo_log_truncate = ON，且innodb_max_undo_log_size设为合理值（如 1G），否则轮转不会触发 - 新增一个 undo 表空间：
CREATE UNDO TABLESPACE undo_004 ADD DATAFILE 'undo_004.ibu'（需 MySQL 8.0.23+） - 将旧表空间设为
INACTIVE：ALTER UNDO TABLESPACE undo_001 SET INACTIVE（成功后需等所有依赖它的事务结束） - 等待状态变为
EMPTY（查information_schema.INNODB_TABLESPACES），再DROP UNDO TABLESPACE undo_001
为什么 innodb_undo_log_truncate 开了也不缩容
因为 truncate 只清理 undo log segment 内部的“已提交日志页”，不回收数据文件本身。文件系统层面的大小不变，只是内部可复用空间变多。
性能影响：频繁 truncate 可能引发短时 I/O 尖峰；兼容性上，MySQL 8.0.23 前不支持动态增删 undo 表空间。
- 检查是否真在轮转：
SHOW STATUS LIKE 'Innodb_undo_log%'，关注Innodb_undo_log_truncated是否递增 - 如果
Innodb_undo_log_written持续上涨但Innodb_undo_log_truncated为 0，说明没触发轮转——大概率是innodb_max_undo_log_size太大或事务太活跃 - 注意：
truncate不等于purge；undo purge 是后台线程做的，受innodb_purge_rseg_truncate_frequency影响
生产环境最稳妥的缩减路径
别碰正在运行的 undo 文件。真要降磁盘占用，就接受“重建”这个事实。
- 用
mysqldump --single-transaction导出（注意大事务会卡住 purge） - 或用
mysqlpump/mydumper加--trx-consistency-only提升一致性 - 初始化新实例时，显式设置
innodb_undo_tablespaces = 2（最小可用数），避免默认 12 个空占位 - 导入后，确认
SELECT COUNT(*) FROM information_schema.INNODB_TABLESPACES WHERE NAME LIKE 'undo%'返回 2
最容易被忽略的一点：备份恢复后，innodb_undo_directory 路径下残留的旧 .ibu 文件必须手动清掉，否则下次启动可能误加载——MySQL 不校验这些文件是否在配置中声明。
