mysql 8.0 初始化时不应设置 innodb_undo_tablespaces，因其自8.0.14起已废弃、8.0.21后彻底移除，设了也无效并触发警告；默认自动创建2个隐式undo表空间（undo_001/undo_002），数量与路径由内核控制，仅innodb_undo_directory可影响其初始存放位置。
MySQL 8.0 默认已启用独立 Undo 表空间，无需在初始化前手动配置 innodb_undo_tablespaces 等参数——除非你明确要覆盖默认行为或部署在旧版兼容模式下。
MySQL 8.0 初始化时还该不该设 innodb_undo_tablespaces
不该设，也设不了有效值。从 MySQL 8.0.14 起，innodb_undo_tablespaces 已被标记为废弃（deprecated），8.0.21 后彻底移除；即使你在 my.cnf 里写上 innodb_undo_tablespaces = 4，启动时会被忽略，日志中会出现警告：[Warning] InnoDB: Ignoring innodb_undo_tablespaces because it is deprecated.
MySQL 8.0 初始化后默认创建 2 个隐式 Undo 表空间（undo_001、undo_002），路径在数据目录下，文件扩展名为 .ibu。这个行为由内核硬编码控制，不依赖配置项。
- 想改数量？必须用 SQL：执行
CREATE UNDO TABLESPACE undo_003 ADD DATAFILE '/var/lib/mysql/undo_003.ibu' - 想删一个？先
ALTER UNDO TABLESPACE undo_003 SET INACTIVE，再DROP UNDO TABLESPACE undo_003 - 路径必须是绝对路径，且需在
innodb_directories列表中，或直接落在 datadir 下
初始化前唯一需要关注的 Undo 相关配置只有 innodb_undo_directory
这个参数在 MySQL 8.0 中仍有效，但仅影响「隐式创建」的那两个默认 Undo 表空间的存放位置。它不能改变数量，也不能用于后续显式创建的表空间（那些必须用 SQL 指定完整路径）。
如果你希望默认生成的 undo_001.ibu 和 undo_002.ibu 不落在数据目录，而是在高速 SSD 上：
- 确保目标目录存在且属主为
mysql用户：mkdir -p /ssd/mysql/undo && chown mysql:mysql /ssd/mysql/undo - 在
my.cnf的[mysqld]段落添加：innodb_undo_directory = /ssd/mysql/undo - 该设置只在首次初始化（
mysqld --initialize）时生效；实例一旦初始化完成，再改此参数重启无效
常见错误：以为删了 ibdata1 就清空了 Undo
MySQL 8.0 的 Undo 已完全脱离 ibdata1，但很多人看到 ibdata1 文件大小稳定，就误判 Undo 没在增长。实际中：
- 大事务未提交时，Undo 表空间（如
undo_001.ibu）会持续膨胀，可能占满磁盘 -
SHOW ENGINE INNODB STATUS\G中的UNDO LOG段才是真实水位，看History list length值是否异常高 -
SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE SPACE_TYPE = 'undo'可查每个 Undo 表空间的FILE_SIZE和ALLOCATED_SIZE -
innodb_undo_log_truncate = ON（默认开启）只对「已失效且空闲」的 Undo 表空间触发回收，不是实时压缩
真正关键的不是初始化前填几个参数，而是初始化后立刻确认 undo_001.ibu 和 undo_002.ibu 是否落在预期路径，并建立对 INFORMATION_SCHEMA.INNODB_TABLESPACES 和 History list length 的常态化监控——这些比任何配置项都更能反映 Undo 健康度。
