mysql 8.0.30+ 必须用 innodb_redo_log_capacity 在线配置 redo log 总容量（单位字节），自动拆为32个均等文件；8.0.29及更早需停库删 ib_logfile* 并改 innodb_log_file_size 和 innodb_log_files_in_group。
MySQL 8.0 的 Redo Log 大小配置不是“改一个参数就行”，而是必须先分清版本：8.0.30+ 用 innodb_redo_log_capacity 在线调总容量；8.0.29 及更早必须停库删 ib_logfile* 并改 innodb_log_file_size 和 innodb_log_files_in_group。混用或误判版本，MySQL 直接启动失败，不是警告。
怎么判断该用哪个参数？看版本再动手
执行 SELECT VERSION();，结果是 8.0.30 或更高？那 innodb_log_file_size 和 innodb_log_files_in_group 已被硬性移除——配置文件里哪怕只留一行注释，启动时也会报 Unknown variable 'innodb_log_file_size'。低于该版本才走传统流程：停库 → 删日志文件 → 改配置 → 启动。
常见误判点：
- 升级后没清理旧配置，以为“只是警告”，结果下次重启服务起不来
- 看到文档写“8.0 支持在线调整”，就默认自己版本也支持，实际用的是 8.0.28
- 在 8.0.30+ 上执行
SET GLOBAL innodb_log_file_size = ...，命令静默失败，变量值不变
8.0.30+ 怎么在线设 Redo Log 总大小？
innodb_redo_log_capacity 是唯一有效参数，单位是字节（不是 MB/G），InnoDB 自动拆成 32 个文件，每个大小 = 总容量 ÷ 32。
实操要点：
- 在线生效：
SET GLOBAL innodb_redo_log_capacity = 2147483648;（即 2GB），无需重启 - 持久化需写入配置文件：
innodb_redo_log_capacity = 2147483648（不能写2G或2GB） - 验证是否真正生效，要查三处：
SELECT @@innodb_redo_log_capacity;、SHOW STATUS LIKE 'innodb_redo_log_capacity_resized';（值应等于变量值）、ls -lh #innodb_redo/#ib_redo*（应有 32 个文件，大小均一） - 底层切换是渐进式，可能持续数秒到几分钟，期间写入不受影响，但监控会看到
ordinary和spare类型文件交替出现
Redo Log 刷新策略怎么配？别只盯 innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit 控制刷盘时机，但它和 Redo Log 大小强耦合：设为 0 或 2 时，日志太小会导致一秒内写满，OS 缓存还来不及落盘就 crash，已提交事务全丢。
关键协同点：
- 若用
innodb_flush_log_at_trx_commit = 1（每事务刷盘），innodb_redo_log_capacity可设小些（如 1–2GB），但不能低于 512MB，否则 checkpoint 频繁，Innodb_log_waits明显上升 - 若用
= 2（每秒刷一次），innodb_redo_log_capacity至少要撑住峰值写入 × 3 秒，例如写入峰值 30MB/s，建议 ≥ 2GB - 别忽略
innodb_log_buffer_size：默认 16MB，大事务（如批量导入）容易撑爆缓冲区，表现为Innodb_log_waits持续非零；起步可设67108864（64MB）
崩溃恢复慢？大概率是 Redo Log 容量远超实际需要
恢复时间 ≈ 待重放日志量 ÷ 磁盘顺序读速度。盲目设 8GB，而实际峰值写入仅 10MB/s，意味着 MySQL 启动时要重放近 15 分钟日志 —— SSD 上也要几十秒，HDD 更可能卡在 Starting crash recovery... 超过 5 分钟。
合理估算方法：
- 查真实压力：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，间隔 30 秒取两次差值 ÷ 30，得每秒平均写入字节数 - 按 RTO（恢复时间目标）反推：若要求 ≤ 5 分钟恢复，且磁盘顺序读速约 100MB/s，则最大可接受日志量 ≈ 5 × 60 × 100×1024×1024 ≈ 30GB；实际设 5–10GB 更稳妥
- OLTP 场景常见值：1–8GB；金融类强一致系统倾向 2–4GB +
innodb_flush_log_at_trx_commit = 1
最常被跳过的一步：改完 innodb_redo_log_capacity 后，不检查 innodb_log_buffer_size 是否匹配——缓冲区太小，再大的日志文件也救不了写入抖动。
