innodb_undo_log_truncate动态开启后无效，因其实现依赖初始化时创建的多个独立undo表空间（innodb_undo_tablespaces≥2），若实例启动时该值为0（默认），所有undo仍在ibdata1中，innodb会静默忽略该参数，必须停库重建undo拓扑才能生效。
不能直接在已运行的 MySQL 5.7 实例上“启用”Undo自动收缩——innodb_undo_log_truncate 开关本身可动态开启，但它的底层依赖（独立 undo 表空间）必须在初始化时就存在。没提前配好 innodb_undo_tablespaces，这个参数开了也完全不生效。
为什么改完 my.cnf 加上 innodb_undo_log_truncate=ON 没用？
因为 innodb_undo_log_truncate 只是“允许截断”的开关，不是“触发截断”的指令。它真正起作用的前提是：系统里已有多个独立的 undo 表空间文件（如 undo001、undo002），且这些文件不是从 ibdata1 里拆出来的“假独立”——而是 MySQL 初始化时就按拓扑创建的。如果实例启动时 innodb_undo_tablespaces=0（默认值），所有 undo 都还在 ibdata1 里，InnoDB 根本不会尝试去 truncate 任何东西，错误日志里也不会报错，只会静默忽略该配置。
必须停库重建 undo 表空间拓扑
这不是调参能解决的问题，是物理结构限制。MySQL 5.7 不支持在线切换 undo 存储方式。要让 innodb_undo_log_truncate 生效，必须：
- 停库，并确保所有事务已提交、purge 已追平（查
SELECT COUNT(*) FROM information_schema.INNODB_TRX应为 0，SHOW ENGINE INNODB STATUS中 HISTORY LIST 尽量小） - 备份全库（
mysqldump -A或xtrabackup），这是唯一兜底手段 - 清空 data 目录下除
mysql、performance_schema等系统库外的所有文件（特别是ibdata1、ib_logfile*、所有undo*文件） - 在
my.cnf中明确设置：innodb_undo_tablespaces = 4 innodb_undo_directory = /var/lib/mysql/undo innodb_undo_logs = 128 innodb_undo_log_truncate = ON innodb_max_undo_log_size = 1073741824 innodb_purge_rseg_truncate_frequency = 32
- 确保
/var/lib/mysql/undo目录存在且 MySQL 进程可写 - 重启 mysqld，此时会自动生成
undo001～undo004四个 10MB 的初始文件
truncate 触发后文件大小不变是正常现象
很多人看到日志里出现 [Note] InnoDB: Truncating tablespace ./undo/undo001 就以为磁盘空间立刻释放了，结果 ls -lh undo/ 发现还是 10MB —— 这不是失败，是 InnoDB 的设计行为。truncate 只是重置表空间内部页分配状态、将 LSN 归零、标记为“逻辑空闲”，但操作系统层面的文件尺寸不会缩小。真正的磁盘空间回收要靠后续写入复用旧页，或手动执行 OPTIMIZE TABLESPACE（MySQL 8.0.30+）；5.7 下只能接受“文件体积不变，但实际可复用空间已恢复”这个事实。
最易被忽略的一点：即使完成上述重建，innodb_undo_log_truncate 也不会立即动作。它每 128 秒检查一次，且只对当前 inactive 的 undo 表空间尝试 truncate，前提是该空间内所有 rollback segment 的历史记录都已被 purge 干净。所以刚重启后，得等 purge 赶上、再等下次检查周期，才能看到首次 truncate 日志。
