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 还是必须停库删文件改 innodb_log_file_size。混用或误判版本会导致启动失败，不是警告，是直接拒绝服务。
查清 MySQL 版本再动配置
执行 SELECT VERSION();，结果为 8.0.30 或更高？那 innodb_log_file_size 和 innodb_log_files_in_group 已被移除，配置文件里保留任一者都会触发启动错误：Unknown variable 'innodb_log_file_size'。低于该版本才走传统流程：停库 → 删 ib_logfile* → 改配置 → 启动。
- 8.0.29 及更早：总日志容量 =
innodb_log_file_size×innodb_log_files_in_group（默认为 2），改完不删旧文件必报错InnoDB: Error: log file ./ib_logfile0 is of different size - 8.0.30+：只认
innodb_redo_log_capacity（单位字节），InnoDB 自动维护 32 个文件，单个大小 = 总容量 ÷ 32 - 升级后没清理旧参数？启动时会打印
[Warning] [MY-013869] Ignored deprecated configuration parameter innodb_log_file_size，但该警告之后若仍存在该参数，后续版本可能直接报错
8.0.30+ 用 innodb_redo_log_capacity 在线调优
innodb_redo_log_capacity 支持 SET GLOBAL 实时生效，无需重启，但底层文件切换是渐进式，可能持续数秒到几分钟。设太大会拖慢崩溃恢复，设太小则触发频繁 checkpoint，写入抖动明显。
- 在线调整示例：
SET GLOBAL innodb_redo_log_capacity = 2147483648;（即 2GB） - 持久化需写入配置文件：
innodb_redo_log_capacity = 2147483648（注意：不是2G或2GB，必须是纯数字字节） - 查看当前值：
SELECT @@innodb_redo_log_capacity; - 看文件分布：
SELECT * FROM performance_schema.innodb_redo_log_files;，type字段区分ordinary（活跃）和spare（待切换）
别把大事务卡顿全怪 Redo Log 文件大小
大事务（如批量导入百万行、含大 BLOB）写入慢，大概率不是 innodb_redo_log_capacity 太小，而是 innodb_log_buffer_size 不足。默认 16MB 容易撑满，导致频繁刷盘、内存拷贝，表现为 Innodb_log_waits 持续上升。
- 查当前值：
SHOW VARIABLES LIKE 'innodb_log_buffer_size'; - 建议起步值：
67108864（64MB）；单事务 redo 日志常超 100MB 时可设134217728（128MB） - 别盲目冲到 512MB 以上——收益快速衰减，且会挤占 InnoDB 内存池
- 该参数只影响未提交事务的内存缓冲，不改变磁盘日志文件大小，也不放大崩溃丢失风险
容量值怎么算才不踩坑
目标不是“越大越好”，而是让 Log sequence number − Last checkpoint at 稳定在总容量的 70% 以下。超过说明日志循环太快，InnoDB 被迫频繁刷脏页，间接加剧延迟。恢复时间 ≈ 重放日志量 ÷ 磁盘顺序读速，SSD 上重放 1GB 日志约需 3–8 秒，HDD 可能超 30 秒。
- 测真实写入压力：
SELECT SUM(VARIABLE_VALUE) FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，隔 30 秒跑两次，差值 ÷ 30 得每秒写入字节数 - 按 RTO（恢复时间目标）反推：若峰值写入 20MB/s、RTO ≤ 5 分钟，则容量 ≈
20*1024*1024*300 ≈ 6144MB（即约 6GB） - OLTP 常见合理范围：1–8 GB；金融类强一致性场景可上 10–20 GB，但必须实测崩溃恢复时间
- 文件系统或磁盘空间不足时，调小
innodb_redo_log_capacity不会立即释放磁盘，要等旧文件自然归档后才删除
真正容易被忽略的是：很多人调大了 innodb_redo_log_capacity 就以为万事大吉，却没盯 SHOW ENGINE INNODB STATUS 里的 sequence number 和 Last checkpoint at 差值，也没验证崩溃后 MySQL 启动是否真能在 RTO 内完成 recovery —— 这两个动作不做，配置就只是纸面参数。
