mysql 8.0 中 alter tablespace undo001 engine=innodb 无效，因该语法不支持 undo 表空间；真正收缩仅靠 purge 线程驱动的 truncate，且必须满足：≥2 个独立 undo 表空间、innodb_undo_log_truncate=on、无长事务阻塞 purge。
MySQL 8.0 中无法“手动触发收缩事务”，但可以手动触发 Undo 表空间的自动截断（truncate）——前提是满足全部前置条件，否则命令无效或静默失败。
为什么 ALTER TABLESPACE undo001 ENGINE=InnoDB 不起作用
这条语句在 MySQL 8.0 中**不会触发任何收缩行为**，它只是对表空间执行一次无意义的存储引擎重载操作。InnoDB 对 ALTER TABLESPACE ... ENGINE=InnoDB 的支持仅限于普通用户表空间，undo 类型表空间不响应此语法。执行后既不会报错，也不会缩小文件，属于典型“看似合理、实则无效”的误操作。
- 错误日志里查不到相关记录，
information_schema.INNODB_TABLESPACES中的FILE_SIZE和ALLOCATED_SIZE完全不变 - 该语句在官方文档中未被列为 undo 管理手段，属社区流传的过时/错误经验
- 真正生效的收缩机制只有一种：由 Purge 线程驱动的
truncate，且必须满足多条件
手动触发 truncate 的唯一可靠方式：强制越界 + 等待轮询
所谓“手动触发”，本质是人为制造触发条件，让 InnoDB 在下一轮检查中立即满足 truncate 要求。核心是让某个 undo 表空间的已用大小超过 innodb_max_undo_log_size，同时确保 purge 已就绪。
- 先确认当前最大阈值：
SELECT @@innodb_max_undo_log_size;（默认 1073741824，即 1GB） - 临时调小阈值（例如设为 10MB），逼迫系统认为“已超标”：
SET GLOBAL innodb_max_undo_log_size = 10485760; - 等待最多 128 秒（
innodb_purge_rseg_truncate_frequency默认值），InnoDB 会检查并尝试截断一个满足条件的 undo 表空间 - 成功后，错误日志会出现类似
[Note] InnoDB: Truncating tablespace ./undo/undo_001的提示 - 恢复原阈值：
SET GLOBAL innodb_max_undo_log_size = 1073741824;
为什么 truncate 后磁盘空间没释放
这是最常被忽略的设计事实：truncate 操作只重置表空间内部结构（LSN、页分配位图等），**不调用操作系统 ftruncate() 或删除文件**，因此 ls -lh undo_001 显示的文件大小完全不变。
- 文件内容被逻辑清空，新事务写入从头开始，但旧空间仍被文件占据
- 磁盘空间真正回收需停库后重建：删掉
undo_001，重启 MySQL 让其自动生成新文件（仅限测试/新环境） - MySQL 8.0.30+ 提供
OPTIMIZE TABLESPACE undo_001;，但该命令也仅优化内部碎片，不缩文件尺寸 - 生产环境若急需腾空间，只能走“加新 undo → 设旧为 inactive → 等 purge 完 → 停库删旧文件”流程
检查是否真能触发的三个硬性前提
缺一不可，否则无论怎么调参都白忙：
- 必须有 ≥2 个独立 undo 表空间（
SELECT * FROM information_schema.INNODB_TABLESPACES WHERE SPACE_TYPE = 'Undo';查数量），ibdata1承载的 undo 不支持 truncate -
innodb_undo_log_truncate必须为ON（MySQL 8.0+ 默认开启，但需确认：SELECT @@innodb_undo_log_truncate;） - 必须无长事务阻塞 purge：
SELECT TRX_ID, TRX_STARTED FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 1;看最早事务是否超 1 小时；同时SHOW ENGINE INNODB STATUS\G中 “HISTORY LIST LENGTH” 应小于 10000
