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 跑出来的数字会严重误导。
