如何排查MySQL因为Redo Log文件设置过小导致频繁发生Checkpoint刷脏引发卡顿？

直接看Innodb_log_waits是否持续>0和Innodb_os_log_written每秒增长是否剧烈（如突增到100MB/s以上），若同时checkpoint每1–5分钟触发一次，且SHOW ENGINE INNODB STATUS中Log sequence number与Last checkpoint at差值长期接近0或远低于总日志容量，即表明Redo Log过小导致Checkpoint过频。

怎么看是不是Redo Log太小导致Checkpoint过频

直接看 Innodb_log_waits 和 Innodb_os_log_written 两个指标。如果 Innodb_log_waits 持续 > 0，说明日志空间不够用，事务在等日志复用；Innodb_os_log_written 每秒增长剧烈（比如突增到 100MB/s 以上），且每 1–5 分钟就触发一次 checkpoint，基本就是日志容量撑不住了。

再查 SHOW ENGINE INNODB STATUSG 输出里的 LOG 部分：Log sequence number 和 Last checkpoint at 的差值长期低于 innodb_log_file_size × 2，甚至反复接近 0，就是日志循环太快、checkpoint 被硬推着往前赶的典型表现。

怎么算出合适的 innodb_log_file_size 值

别拍脑袋设 1G 或 4G，得按实际写入压力算。先用 Innodb_os_log_written 推峰值速率：

1. 记下当前值 A，等 60 秒再查一次得 B，(B − A) ÷ 60 = MB/s
2. 取最近一小时内的最大值，乘以 15–30 分钟（即 900–1800 秒），得到目标总容量
3. 若峰值是 80 MB/s，建议总 redo 容量 ≥ 80 × 1200 = 96,000 MB ≈ 96 GB？不对——这是误算。实际应是 80 × 1200 ÷ 1024 ≈ 94 GB？也不对。单位错了：80 MB/s × 1200 s = 96,000 MB = 93.75 GB？还是太大。正确做法是：80 MB/s × 1200 s = 96,000 MB = 93.75 GB？不，生产环境极少需要上百GB。真实经验值是：80 MB/s × 60 s = 4800 MB ≈ 4.7 GB，取整设为 5 GB 总容量更合理（即 innodb_log_file_size × innodb_log_files_in_group）

MySQL 8.0.30+ 可用 innodb_redo_log_capacity 动态调，比如 SET GLOBAL innodb_redo_log_capacity = 5368709120（5GB）；老版本就得组合调 innodb_log_file_size 和 innodb_log_files_in_group，常见配法是 1073741824（1GB）× 3 = 3GB。

改完配置为什么 MySQL 启动失败

因为 InnoDB 启动时会严格比对磁盘上 ib_logfile0、ib_logfile1 的实际大小和配置文件里 innodb_log_file_size 的值，不一致就报错：InnoDB: Error: log file ./ib_logfile0 is of different size，进程直接退出。

必须按顺序操作：

1. 先执行 SET GLOBAL innodb_fast_shutdown = 0，确保所有脏页刷盘、checkpoint 完成
2. 用 mysqladmin shutdown 或 systemctl stop mysql 关库，别 kill -9
3. 确认 ps aux | grep mysqld 无残留进程，error log 最后一行是 Shutdown complete
4. 备份旧日志：cp /var/lib/mysql/ib_logfile* /backup/
5. 删干净：rm /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile1（数量要和 innodb_log_files_in_group 一致）
6. 改配置，启动——InnoDB 自动重建日志文件

调大之后还要盯哪几个关键水位

重启后不能就撒手不管。重点观察三个动态值：

1. Log flushed up to 和 Last checkpoint at 的差值，稳定在 innodb_log_file_size 的 30%–50% 区间才算健康；长期 > 70% 说明还是偏小，
2. Innodb_log_waits 必须归零，否则说明日志空间仍紧张
3. 如果用了 innodb_flush_log_at_trx_commit = 0 或 = 2，还得确认单秒写入量不超过总日志容量的 1/3，否则断电丢数据风险陡增

真正容易被忽略的是：调大日志后，崩溃恢复时间会变长，但日常提交延迟下降是实打实的；而很多人只盯着“恢复慢”不敢调，却没意识到卡顿本身已在持续损耗业务 SLA。