MySQL 5.7 不能默认用独立 Undo 表空间，因其需全新初始化实例且依赖 innodb_undo_log_truncate=ON、innodb_undo_tablespaces≥2 等严格前提，旧实例无法在线切换。
Undo Log 为什么不能默认用独立表空间
MySQL 5.7 默认把 Undo Log 和系统表空间（ibdata1）混在一起，不是设计疏忽，而是为了兼容老版本和简化部署。但一旦事务量大、长事务多，ibdata1 就会持续膨胀且无法收缩，连带影响备份恢复速度和 purge 效率。
独立表空间本质是把 Undo Log 拆成多个固定大小的 undo_001.ibu、undo_002.ibu 等文件，由 InnoDB 自动轮转和清理——但这个能力在 MySQL 5.7 才正式稳定，在 5.6 只是实验性支持，8.0 则默认启用并改用更轻量的「segment-based」管理方式。
MySQL 5.7 配置 innodb_undo_tablespaces 的硬性前提
这个参数不是设了就生效，它依赖一组联动配置，漏掉任何一个都会回退到系统表空间。
-
innodb_undo_log_truncate = ON必须开启，否则即使有多个表空间也不会触发轮转和截断 -
innodb_undo_tablespaces值必须 ≥ 2（官方要求最小值），设为 0 或 1 会被忽略 -
innodb_undo_directory推荐显式指定路径（如/var/lib/mysql/undo），避免和数据目录混在一起，也方便后续挂单独磁盘 - 实例必须是**全新初始化**，或已执行过
mysqld --initialize；已有运行中的库无法在线切换，强行改参数重启会报错Cannot enable undo log truncation when undo tablespace is not present
示例配置段：
innodb_undo_tablespaces = 4 innodb_undo_directory = /var/lib/mysql/undo innodb_undo_log_truncate = ON innodb_undo_logs = 128
MySQL 8.0 不再需要手动配 innodb_undo_tablespaces
8.0 默认启用独立 Undo 表空间，且名字固定为 undo_001、undo_002，位于数据目录下，不走 ibdata1。你不需要设 innodb_undo_tablespaces，它已被标记为 deprecated。
真正要调的是：
-
innodb_undo_tablespaces：已废弃，设了也不生效（启动时会警告） -
innodb_undo_log_truncate：仍有效，控制是否允许自动截断旧 Undo 段 -
innodb_max_undo_log_size：替代旧版的innodb_undo_logs，单位字节，默认 1G，超限后触发截断 - 新增
innodb_undo_retention：单位秒，默认 1210（约 20 分钟），表示 Undo 记录至少保留多久才允许被 purge —— 这个值太小容易导致Snapshot too old错误
常见错误现象和排查线索
配置完重启没效果？大概率卡在这些地方：
- 查
SHOW VARIABLES LIKE 'innodb_undo%';，发现innodb_undo_tablespaces显示为 0 → 说明初始化时没满足前提（比如不是新实例，或没关innodb_undo_log_truncate） - 看错误日志出现
InnoDB: Unable to create undo tablespace→ 路径不可写，或磁盘满，或 SELinux 拦截 - 执行大事务后
ls -lh undo_*.ibu没增长 → 检查innodb_undo_log_truncate是否为 OFF，或innodb_undo_logs（5.7）设得太小（低于 32）导致复用率高，看不出轮转 - MySQL 8.0 下看到
undo_001文件但大小始终 10M → 正常，8.0 使用 segment 复用机制，不会像 5.7 那样按事务量线性增长
最易被忽略的一点：Undo 表空间文件一旦生成，就不能靠删文件来“重置”——InnoDB 启动时会校验 header，缺失或损坏直接拒绝启动。真要重来，得停库、删文件、清 ibdata1（仅限新实例）、再初始化。
