MySQL 5.7 的 innodb_undo_tablespaces 是初始化时固化参数，实例启动后无法动态修改，必须全新初始化才能生效；它决定 undo 是否拆分为独立文件（如 undo001.ibu），且数量在首次启动时即固定，后续改配置重启无效，需清空数据目录并重新初始化。
因为 innodb_undo_tablespaces 是只读初始化参数，MySQL 5.7 实例一旦启动完成，就无法动态修改它的值。
innodb_undo_tablespaces 属于“初始化时固化”的参数
这个参数不是运行时可调的全局变量，它决定的是 MySQL 启动时是否创建独立的 undo 表空间文件（如 undo001、undo002），以及创建几个。InnoDB 在实例第一次初始化（即首次启动并生成 ibdata1 和日志文件时）就根据该值规划 undo 存储拓扑——要么全部放在 ibdata1 中（innodb_undo_tablespaces=0，默认值），要么拆成多个独立文件存到 innodb_undo_directory 下。
一旦初始化完成，整个 undo 存储结构就固定了。后续即使你改配置、执行 SET GLOBAL 或热重载配置，InnoDB 都会直接忽略 innodb_undo_tablespaces 的新值，错误日志里也不会报错，只会静默不生效。
- 查当前值：
SHOW VARIABLES LIKE 'innodb_undo_tablespaces';返回的是启动时读取的值，不是实时配置文件里的值 - 验证是否已启用独立表空间：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE 'undo%';—— 如果结果为空，说明仍用ibdata1 - 不能靠
mysqladmin reload或FLUSH PRIVILEGES生效，这些命令对它完全无效
为什么不能在线调整？底层物理结构不支持
MySQL 5.7 的 undo 存储机制是“启动即定型”：undo 段（rollback segment）的分配、rseg header 的位置、事务系统页（TRX_SYS）中记录的 rseg 数量，全部在初始化阶段硬编码进系统表空间或独立文件头里。没有迁移路径，也没有后台线程能重建 undo 拓扑。
这意味着：
- 你不能把
ibdata1里的 undo 数据“搬出来”到新 undo 文件——InnoDB 没提供这种迁移命令 - 也不能把已有
undo001扩容为两个——innodb_undo_tablespaces控制的是初始文件个数，不是运行时可增减的池子 - 哪怕你手动创建
/var/lib/mysql/undo/undo002文件，InnoDB 启动时也不会识别它，除非innodb_undo_tablespaces在启动前就设为 ≥2
重启不是目的，停库重建才是关键动作
很多人误以为“改完配置重启服务”就够了，但真正起作用的是：停库 → 清空数据目录（除系统库外）→ 用新配置重新初始化 → 启动。否则，旧的 ibdata1 还在，InnoDB 会继续沿用原有结构。
典型失败场景：
- 只改
my.cnf并systemctl restart mysql→ 日志里看不到 undo 文件生成，INNODB_TABLESPACES查询仍为空 - 没清空
ibdata1就重启 → InnoDB 发现已有系统表空间，直接跳过 undo 拓扑重建逻辑 - 忘记提前创建
innodb_undo_directory目录或赋权 → 启动失败，报错Cannot create undo tablespace
真正需要警惕的，是那个“静默忽略”行为：没报错、没警告、查询看起来正常，但 innodb_undo_log_truncate 始终不会触发——因为你根本没有独立 undo 表空间可 truncate。
