innodb_redo_log_capacity设过大反而更慢，因其导致checkpoint频率过低、脏页堆积、后台刷脏压力集中爆发，并延长崩溃恢复时间；MySQL 8.0.30+已废弃innodb_log_file_size，保留将导致启动失败，须仅用innodb_redo_log_capacity（单位字节）并结合真实写入速率与RTO合理配置。
写入慢八成不是磁盘或CPU瓶颈，而是innodb_redo_log_capacity配得过大或过小，且没匹配真实写入压力。
为什么innodb_redo_log_capacity设大了反而更慢？
MySQL 8.0.30+ 已废弃 innodb_log_file_size，强行保留会直接启动失败：Unknown variable 'innodb_log_file_size'。但很多人把旧配置照搬过来，盲目设成 4GB 或 8GB，结果：
- 日志容量远超实际每秒写入量 → checkpoint 频率极低 → 大量脏页堆积 →
Innodb_buffer_pool_pages_dirty飙升 → 后台刷脏压力集中爆发 - 事务提交时虽不强制 fsync，但 log buffer 快速填满后触发同步刷盘（
innodb_log_waits > 0），写入抖动明显 - 崩溃恢复时间线性增长：重放 8GB 日志在普通 SSD 上可能耗时 2–3 分钟，期间服务不可用
怎么查当前真实写入压力？
别猜，用 performance_schema 算出每秒平均写入字节数：
SELECT SUM(VARIABLE_VALUE) FROM performance_schema.global_status WHERE VARIABLE_NAME LIKE 'Innodb_os_log_written';
间隔 30 秒执行两次，差值 ÷ 30 就是当前平均写入速率（单位：字节/秒）。例如：
- 第一次返回 1234567890
- 第二次返回 1298765432
- 差值 = 64197542 ÷ 30 ≈ 2.14 MB/s
再结合你的 RTO（比如要求 5 分钟内恢复），目标容量 ≈ 2.14 × 1024 × 1024 × 300 ≈ 670MB → 建议设为 innodb_redo_log_capacity = 1073741824（1GB）
调完参数后必须验证的三个关键指标
光改参数没用，得盯运行时行为。执行 SHOW ENGINE INNODB STATUS\G 后重点看：
-
Log sequence number和Last checkpoint at的差值：持续 > 总容量的 70% → 日志太小，checkpoint 过密；长期 -
History list length：若 > 5000，说明 undo 积压，可能拖慢写入（尤其带大事务的 OLTP） -
Log buffer段里是否有log buffer wait字样：有则说明innodb_log_buffer_size不够，需同步调大（建议从默认 16MB 起步，按写入峰值的 1–2 秒缓冲量设）
在线调整和常见误操作
innodb_redo_log_capacity 支持在线修改，但要注意：
- 调大：立即生效，InnoDB 自动创建新日志文件，旧文件逐步归档
- 调小：不会立刻删文件，等旧日志自然归档后才释放空间 —— 所以磁盘空间不会马上回收
- 绝对不要同时保留
innodb_log_file_size和innodb_redo_log_capacity：前者会导致 MySQL 拒绝启动 - 别只改 session 级别：必须
SET GLOBAL innodb_redo_log_capacity = ...，否则新连接仍用旧值
最常被忽略的一点：调参只是手段，不是终点。真正稳定的写入表现，依赖于日志容量、buffer 大小、刷脏节奏三者与业务写入模式的匹配 —— 没有“通用最优值”，只有“当前负载下最不差的那个”。
