mysql 8.0.30+ 必须用 innodb_redo_log_capacity 替代已废弃的 innodb_log_file_size 等参数，否则启动失败；需验证版本、检查 #innodb_redo 目录、实测写入速率并按 rto 计算合理容量，支持在线调整但需关注恢复时间与 i/o 影响。
MySQL 8.0.30+ 升级后，innodb_log_file_size 和 innodb_log_files_in_group 已被废弃，继续保留会直接导致启动失败：Unknown variable 'innodb_log_file_size'。必须切换到 innodb_redo_log_capacity 这一动态参数，否则数据库根本起不来。
确认 MySQL 版本与当前 redo log 架构
先验证是否已进入新架构，避免误操作旧参数：
- 执行
SELECT VERSION();确认 ≥ 8.0.30；若低于该版本，仍需用innodb_log_file_size+ 重启方式调整 - 检查 datadir 下是否存在
#innodb_redo目录：ls -l $DATADIR/#innodb_redo/；有则说明已启用动态 redo log - 查当前容量：
SHOW VARIABLES LIKE 'innodb_redo_log_capacity';；默认仅 104857600 字节（100MB），远不够高并发场景 - 若看到错误
Unknown variable 'innodb_log_file_size'，说明配置文件里还残留旧参数，必须删掉
计算并设置合理的 innodb_redo_log_capacity
这个值不是拍脑袋定的，它直接决定崩溃恢复耗时和 checkpoint 频率。设小了写放大、抖动大；设大了恢复慢、关机也拖沓。
- 实测峰值写入速率：每 30 秒执行一次
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，两次差值 ÷ 30 → 得出 B/s - RTO（恢复时间目标）要明确：比如要求崩溃后 5 分钟内恢复，则容量上限 ≈ 峰值写入速率 × 300
- 举例：实测峰值 22MB/s（23068672 B/s）→ 推荐值 ≈ 23068672 × 300 = 6920601600（约 6.5GB）
- SSD 环境可压缩 20%～30%，HDD 建议保留余量；线上建议从 4GB（4294967296）起步，再根据
SHOW ENGINE INNODB STATUS\G中 Log sequence number 与 Last checkpoint at 的差值动态调优
在线调整与效果验证要点
innodb_redo_log_capacity 支持运行时修改，但行为有细节差异，容易踩坑：
- 执行
SET GLOBAL innodb_redo_log_capacity = 4294967296;后，InnoDB 会自动创建新#ib_redo*文件，旧文件不立即删除，而是等归档自然释放 - 调整后立刻检查：
SELECT FILE_NAME, SIZE_IN_BYTES FROM performance_schema.innodb_redo_log_files;，确认新文件已生成且大小接近总容量 / 32 - 重点盯
SHOW ENGINE INNODB STATUS\G里的三处：
– Log sequence number 和 Last checkpoint at 差值，健康水位应在总容量的 30%～70%；长期 – Log flushed up to 和 Log written up to 差值若常 > 100MB，说明刷盘能力跟不上，可能需调大innodb_log_buffer_size
– 若崩溃前Innodb_os_log_written增速突增，而恢复时扫描日志耗时远超理论值（如 4GB 日志重放 > 20 秒），优先排查磁盘 I/O 或文件系统缓存块对齐问题 - 别忽略
innodb_log_write_ahead_size：设为 4096 或 8192（匹配 OS page cache），可避免 read-on-write 导致的隐式延迟
真正容易被忽略的是：容量调大后，innodb_fast_shutdown=1 下的崩溃恢复时间会线性增长，而 innodb_fast_shutdown=0 时关机也会变慢——这不是 bug，是设计使然。所以 RTO 和运维窗口必须同步评估，不能只看吞吐数字。
