MySQL 8.0.30+中innodb_redo_log_capacity配过大反致写入抖动、脏页堆积及崩溃恢复延长；须用performance_schema实测每秒写入量（差值÷30），再乘RTO（如300秒）得合理容量，建议取2的幂次（如1GB），并删除已废弃的innodb_log_file_size配置。
别直接设 4GB 或 8GB —— MySQL 8.0.30+ 中 innodb_redo_log_capacity 配得过大，反而导致写入抖动、脏页堆积、崩溃恢复超长，是写入慢的头号隐性原因。
查真实写入压力，别靠经验猜
你当前每秒往 redo 日志里写多少字节？这个数决定容量下限。靠“别人说要 2GB”或“我磁盘大就设 8GB”是最常见误操作。
- 执行两次
SELECT SUM(VARIABLE_VALUE) FROM performance_schema.global_status WHERE VARIABLE_NAME LIKE 'Innodb_os_log_written';，间隔 30 秒 - 差值 ÷ 30 = 平均写入速率（单位：字节/秒）
- 例如差值为 64197542 → ≈ 2.14 MB/s
- 再乘以你的 RTO（比如 5 分钟 = 300 秒）→ 目标容量 ≈ 2.14 × 1024 × 1024 × 300 ≈ 670MB
- 建议向上取整到最近的 2 的幂次，如设为
innodb_redo_log_capacity = 1073741824（1GB）
在线调整 innodb_redo_log_capacity 的实操要点
该参数支持运行时修改，但行为有细节差异，不注意会误判效果。
- 调大：立即生效，InnoDB 自动创建新大小的日志文件，旧文件逐步归档；
SHOW ENGINE INNODB STATUS\G中 Log sequence number 和 Last checkpoint at 差值会缓慢收敛 - 调小：不会立刻删文件，等旧日志自然归档后才释放磁盘空间 —— 所以
du -sh #innodb_redo/看不到立竿见影的回收 - 必须删掉配置文件里的
innodb_log_file_size和innodb_log_files_in_group，否则启动报错：Unknown variable 'innodb_log_file_size' - 持久化需用
SET PERSIST innodb_redo_log_capacity = ...，或手动写入 my.cnf
调完必须盯住的三个运行时指标
改完参数不验证，等于没调。重点关注 SHOW ENGINE INNODB STATUS\G 输出中这几处：
- Log sequence number 和 Last checkpoint at 的差值：若持续 > 总容量的 70%，说明日志太小，checkpoint 过密，频繁刷脏拖慢写入
- History list length：若长期 > 5000，undo 积压严重，尤其在 OLTP 大事务场景下会反向卡 redo 写入
-
Log buffer 段是否有
log buffer wait字样：有则说明innodb_log_buffer_size不够，需同步加大（建议从 16MB 起步，按峰值写入量的 1–2 秒缓冲量设）
文件结构和路径陷阱
MySQL 8.0.30+ 的 redo 日志固定为 32 个文件，存于 datadir/#innodb_redo/ 下，命名如 #ib_redo31（活跃）或 #ib_redo48_tmp（备用），单个大小 = innodb_redo_log_capacity / 32。
- 若想自定义路径，必须通过
innodb_log_group_home_dir指向一个**已存在且含#innodb_redo子目录**的路径，例如：/data/mysql/redo_log/#innodb_redo - 直接设
innodb_log_group_home_dir = /data/mysql/redo_log会启动失败，报错：Neither found #innodb_redo subdirectory, nor ib_logfile* files in ... - 不要手动删
#ib_redo*文件 —— InnoDB 自己管理归档与清理，误删会导致实例无法启动
真正卡住性能的，往往不是磁盘或 CPU，而是 redo 日志容量与业务写入节奏脱节。差值算不准、指标不盯紧、路径配错，这三个点最容易被跳过，也最常引发线上写入延迟突增。
