SQL innodb_log_file_size / innodb_log_files_in_group 的 redo log 配置经验公式

innodb_log_file_size建议设为峰值每秒事务日志量×60～90秒，避免频繁checkpoint；需根据磁盘类型（ssd可设4g、hdd不超2g）、crash恢复时间容忍度及真实混合负载测试确定，调整须停机并严格校验配置与文件一致性。

innodb_log_file_size 设置多大才不拖慢写入又避免频繁 checkpoint

直接看结论：innodb_log_file_size 建议设为「峰值每秒事务日志量 × 60～90 秒」，不是总内存比例，也不是磁盘空间的百分比。很多人按 innodb_buffer_pool_size 的 25% 硬套，结果 redo log 太小，导致频繁刷脏页、Waiting for checkpoint 堆积。

常见错误现象：SHOW ENGINE INNODB STATUS 里 Log sequence number 和 Last checkpoint at 差距长期超过 1GB；Innodb_os_log_written 每秒突增后骤降，呈锯齿状；写入吞吐卡在 2k–3k TPS 上不去。

• 用 mysqladmin ext -i1 | grep Innodb_os_log_written 持续采样 5 分钟，取稳定写入峰值（单位字节/秒）
• 乘以 75（折中值），再向上取整到 256MB 倍数（如 1G、2G、4G）——InnoDB 要求每个 ib_logfile 大小是 512 字节对齐，实际部署中 256MB 是最小安全粒度
• 避免设成奇数 GB（如 1.5G），某些旧版本 MySQL 会静默截断或启动失败
• SSD 上可适当放大（比如 4G），但 HDD 上超过 2G 反而可能因单次 write latency 上升拉低吞吐

innodb_log_files_in_group 改成 2 还是 3？别只看文档说“默认 2”

innodb_log_files_in_group 不影响性能，只影响容错窗口和重启恢复时间。设成 3 并不会让写更快，但能多扛一次未刷盘的 log file 损坏；设成 2 在大多数场景已足够，改它之前先确认你真需要这个冗余。

使用场景：主从切换频繁、binlog + redo 双写一致性要求高、dba 对 crash recovery 时间敏感（比如不能超 30 秒）。

• MySQL 5.6+ 默认就是 2，官方没推荐 3，因为 InnoDB 自身有 checksum 和 doublewrite buffer 保障单文件损坏可恢复
• 改成 3 后，ib_logfile0 写满会轮转到 ib_logfile1，再写满轮到 ib_logfile2，最后回绕——总 redo 容量 = innodb_log_file_size × innodb_log_files_in_group
• 修改该值必须停机：删掉所有 ib_logfile*（确保 shutdown 干净，否则启动报 Invalid log file size）
• 不要和 innodb_log_file_size 同时调——一次只动一个参数，否则无法定位是哪个引起 mysqld 启不来

调整后 MySQL 启不起来？重点检查这三处硬编码校验

改完 innodb_log_file_size 或 innodb_log_files_in_group 启动失败，90% 出在配置与物理文件不匹配。InnoDB 启动时会严格比对 ibdata1 头部记录的 log 配置和 my.cnf 中的值，不一致就拒启。

典型错误信息：InnoDB: Error: log file ./ib_logfile0 is of different size 或 Plugin 'InnoDB' init function returned error。

• 确认 mysqld 是干净 shutdown：查 error.log 最后一行是否含 Shutdown completed，不是 Killed 或 signal 9
• 删 ib_logfile* 前，先备份（哪怕只是 cp ib_logfile0 /tmp/），防止误删后无法回退
• 检查 my.cnf 是否被多个配置段覆盖：比如 [mysqld] 下写了，但 [server] 或 [mysqld-5.7] 里又定义了不同值，用 mysqld --print-defaults 看最终生效值

为什么线上不敢随便调大 innodb_log_file_size？真实代价在这儿

调大 innodb_log_file_size 最直接的代价不是磁盘空间，而是 crash recovery 时间变长——MySQL 启动时要重放所有未 checkpoint 的 redo，日志越大，重放越久。线上库若设成 8G，crash 后可能卡住 3–5 分钟才对外提供服务。

另一个隐性成本：大 redo 文件会让 fsync() 延迟更抖动，尤其在机械盘或混用其他 I/O 的云盘上，可能把 innodb_flush_log_at_trx_commit=1 的事务响应时间从 1ms 拉到 10ms+。

• 如果业务能接受 innodb_flush_log_at_trx_commit=2，那 innodb_log_file_size 可以略保守（比如 1G），靠 OS cache 缓冲写压力
• 监控 Innodb_log_waits：大于 0 就说明 redo 写满太快，必须调大，而不是等 slow query log 报告写入慢
• 云数据库（如 RDS）通常禁用手动调该参数，因为底层共享存储的 fsync 行为不可控，强行调反而触发平台自动熔断

redo log 配置没有银弹，峰值写入量、磁盘类型、可用停机窗口、故障恢复 SLA —— 四个变量少一个都定不准值。测的时候别只压单表，得模拟真实业务混合读写流量，否则 sysbench 跑出来的数字会严重误导。