MySQL 8.0 的 redo log 和 undo log 路径仅在初始化前通过 innodb_log_group_home_dir 和 innodb_undo_directory 设置才生效，运行时修改配置重启无效；默认 undo 文件路径固化于数据字典，新增表空间须用 SQL 指定绝对路径，innodb_undo_tablespaces 已废弃。

MySQL 8.0 的 redo log 和 undo log 存储路径不能靠“改配置重启”随意迁移，redo log 路径由 innodb_log_group_home_dir 控制但仅在初始化前有效，undo log 路径则必须通过 innodb_undo_directory 在初始化前指定，且仅影响默认生成的两个 undo_001.ibu 和 undo_002.ibu 文件。

修改 redo log 存放目录需重建实例

MySQL 8.0 不支持运行时移动 ib_logfile0 和 ib_logfile1。即使你设置了 innodb_log_group_home_dir = /ssd/mysql/redolog 并重启，mysqld 启动时仍会报错或直接忽略该参数，继续使用原数据目录下的日志文件。

• 真正生效的唯一时机是初始化实例前：在执行 mysqld --initialize 前，把 innodb_log_group_home_dir 写进 my.cnf 的 [mysqld] 段，且目标路径必须存在、属主为 mysql 用户
• 若实例已运行，想换路径，只能停库 → 备份数据 → 删除 ib_logfile* 和 ibdata1（注意：这会丢失所有非独立表空间数据）→ 修改配置 → 重新初始化 → 恢复逻辑备份（如 mysqldump 或 mysqlpump）
• innodb_log_group_home_dir 默认值是 ./，即指向 datadir；它不支持相对路径以外的符号链接，建议用绝对路径

undo log 路径只在初始化时起效，且仅限默认两个文件

innodb_undo_directory 是 MySQL 8.0 初始化前唯一应设置的 undo 相关参数，它不控制后续手动创建的 undo 表空间位置。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 目标目录必须提前创建并授权：mkdir -p /ssd/mysql/undo && chown mysql:mysql /ssd/mysql/undo
• 配置写入 my.cnf：innodb_undo_directory = /ssd/mysql/undo
• 初始化完成后，该参数再修改并重启，不会移动已存在的 undo_001.ibu 和 undo_002.ibu——它们的路径已固化在数据字典中
• 新增表空间（如 undo_003）必须用 SQL 指定绝对路径：CREATE UNDO TABLESPACE undo_003 ADD DATAFILE '/ssd/mysql/undo/undo_003.ibu'，且该路径需在 innodb_directories 列表中，或直接落在 datadir 下

别碰 innodb_undo_tablespaces，它在 8.0.14+ 已废弃

这个参数在 MySQL 8.0.14 引入弃用警告，8.0.21 起彻底移除。设了不仅无效，还会在错误日志里反复打印：[Warning] InnoDB: Ignoring innodb_undo_tablespaces because it is deprecated.

• 如果你在 my.cnf 里写了 innodb_undo_tablespaces = 4，mysqld 启动时会忽略它，并继续只生成默认的两个 undo 表空间
• 运行时表空间数量完全由 SQL 控制：CREATE/DROP 决定，不是配置项驱动的
• 误设该参数还可能干扰运维判断——比如你以为有 4 个 undo 表空间，实际只有 2 个活跃，导致 innodb_undo_log_truncate 无法触发（因为要求至少两个 TRUNCATE_STATUS = truncate_ready）

路径分离后，务必确认 I/O 能力匹配

把 redo 和 undo 放到 SSD 路径看似合理，但如果没做压测或监控，容易暴露隐藏瓶颈：

• redo log 是顺序写密集型，对磁盘随机 IOPS 几乎无要求，但吞吐和延迟敏感；SSD 上 innodb_log_file_size = 2G + innodb_log_files_in_group = 2 是较稳组合
• undo 表空间是随机读写混合型，尤其在高并发长事务场景下，undo_*.ibu 文件频繁被 purge 线程访问；若放在与数据文件共用的机械盘上，I/O 争抢会导致 trx_rseg_history_len 持续升高
• 检查是否真走到了目标路径：SELECT NAME, FILE_NAME FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE 'undo%'; —— 这个结果比配置文件更可信