MySQL 8.0 默认启用独立Undo表空间，无需初始化时配置innodb_undo_tablespaces（该参数自8.0.14废弃、8.0.21移除），默认创建undo_001.ibu和undo_002.ibu；数量与路径由内核控制，仅innodb_undo_directory影响初始存放位置；增删表空间须用SQL（如CREATE/DROP UNDO TABLESPACE），且路径须为绝对路径、扩展名为.ibu。
MySQL 8.0 的 UNDO 表空间不需要“独立配置”——它默认就是独立的，且不能靠配置文件初始化时设数量。你看到的“需要配置”，大概率是沿用了 5.7 或更早版本的习惯，或文档没更新。真正要做的，是理解它已变成可在线管理的 SQL 对象，而不是靠 my.cnf 参数硬编码。
innodb_undo_tablespaces 在 8.0 中设了也白设
这个参数从 MySQL 8.0.14 起被标记为废弃，8.0.21 后彻底移除。即使你在 my.cnf 里写上 innodb_undo_tablespaces = 4：
- mysqld 启动时会打印警告：
[Warning] InnoDB: Ignoring innodb_undo_tablespaces because it is deprecated. - 实例仍只创建默认的 2 个隐式表空间：
undo_001.ibu和undo_002.ibu - 这两个文件路径由
innodb_undo_directory决定（仅对初始化生效），但数量、名字、是否启用全由内核控制，不认这个参数
真正该用 SQL 管理，不是改配置
MySQL 8.0.14+ 把 UNDO 表空间当作普通数据库对象，增删改都走 SQL：
- 加一个：执行
CREATE UNDO TABLESPACE undo_003 ADD DATAFILE '/var/lib/mysql/undo_003.ibu'（注意必须是绝对路径，扩展名必须是.ibu） - 停用一个：先
ALTER UNDO TABLESPACE undo_003 SET INACTIVE（确保无活跃事务使用该空间） - 删一个：再
DROP UNDO TABLESPACE undo_003 - 查当前状态：
SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG'
innodb_undo_directory 只影响初始化时的存放位置
这个参数在 8.0 里还有效，但作用非常有限：
- 只在首次运行
mysqld --initialize时起作用，决定那两个默认undo_001.ibu和undo_002.ibu放哪 - 必须确保目录存在、属主为
mysql用户，否则初始化失败 - 实例一旦初始化完成，再改这个参数并重启，不会移动已有文件，也不会影响后续 SQL 创建的表空间
- 后续用
CREATE UNDO TABLESPACE创建的，路径必须显式写死，且需落在innodb_directories列表中或直接在datadir下
最容易被忽略的一点：UNDO 表空间膨胀往往不是因为“没配好”，而是因为长事务卡住 purge 线程，导致历史版本无法清理。这时候看 ibdata1 大小没用——得查 SHOW ENGINE INNODB STATUS\G 里的 History list length，或者监控 information_schema.innodb_trx 里运行超时的事务。
