MySQL 8.0的innodb_undo_log_truncate=ON默认开启但不生效，必须同时满足四个硬性条件：innodb_undo_tablespaces≥2、innodb_max_undo_log_size>0、至少一个undo表空间处于INACTIVE/empty状态、purge推进使HISTORY LIST LENGTH≤500。
MySQL 8.0 的 innodb_undo_log_truncate=ON 默认已开启，但几乎从不自动生效——不是配置漏了，而是四个硬性条件全得满足，缺一不可。
检查是否满足自动截断的四大前提
光设 SET GLOBAL innodb_undo_log_truncate = ON 没用。InnoDB 启动截断前会静默校验以下全部条件，任一失败就跳过：
-
innodb_undo_tablespaces≥ 2：必须有至少两个独立 undo 表空间（如undo_001.ibu、undo_002.ibu）。若为 0 或 1，该参数直接被忽略 -
innodb_max_undo_log_size> 0：默认 1024MB，设为 0 或负值即禁用截断逻辑 - 至少一个 undo 表空间处于
INACTIVE或empty状态：活跃事务未退出前，InnoDB 不敢动它 - Purge 必须跟上：查
SHOW ENGINE INNODB STATUS\G中的HISTORY LIST LENGTH，必须稳定在 500 以下；同时确认purge_trx_count在持续下降
为什么 ALTER UNDO TABLESPACE xxx SET INACTIVE 总失败
最常见报错 ERROR 3655 (HY000): Cannot set undo tablespace inactive，本质不是权限或语法问题，而是 MySQL 强制保底策略：
- 系统要求始终保留 ≥ 2 个
ACTIVEundo 表空间，防止轮换中断 - 若当前只有
undo_001和undo_002，执行ALTER UNDO TABLESPACE undo_001 SET INACTIVE必然失败 - 正确做法是先新增第三个：
CREATE UNDO TABLESPACE undo_003 ADD DATAFILE 'undo_003.ibu' - 再设旧的为 inactive：
ALTER UNDO TABLESPACE undo_001 SET INACTIVE - 最后查状态：
SELECT NAME, STATE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE 'undo%'，确认undo_001已变为INACTIVE
truncate 后文件大小不变？这是设计，不是 bug
看到 du -h undo_001.ibu 仍是 71GB，别急着删文件或怀疑 truncate 失败：
-
TRUNCATE只做逻辑重置：清空页分配位图、重置 LSN、让新事务从头写入 - 操作系统层面的文件尺寸完全不变，
ls -lh看不到任何变化 - 真正释放磁盘空间的唯一方式是
DROP UNDO TABLESPACE undo_001，但前提是它已为INACTIVE且HISTORY LIST LENGTH足够低 - MySQL 8.0.30+ 支持
OPTIMIZE TABLESPACE undo_001，但它只优化内部碎片，不缩物理文件
手动“触发”截断的可靠方式
所谓“手动”，其实是人为制造触发条件，逼 InnoDB 下一轮检查就动作：
- 先确认当前阈值：
SELECT @@innodb_max_undo_log_size（默认 1073741824） - 临时压低阈值：
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 - 注意：这不会释放磁盘空间，只是加速逻辑清理；后续仍需走
SET INACTIVE → DROP才能删文件
真正卡住人的从来不是命令怎么写，而是 purge 进度和事务生命周期——HISTORY LIST LENGTH 降不下来，所有操作都只是原地打转。盯着 INFORMATION_SCHEMA.INNODB_TRX 找那个运行超 10 分钟、trx_query IS NULL 的空闲连接，比调参管用十倍。
