直接看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 STATUS\G 输出里的 LOG 部分：Log sequence number 和 Last checkpoint at 的差值长期低于 innodb_log_file_size × 2，甚至反复接近 0，就是日志循环太快、checkpoint 被硬推着往前赶的典型表现。
怎么算出合适的 innodb_log_file_size 值
别拍脑袋设 1G 或 4G，得按实际写入压力算。先用 Innodb_os_log_written 推峰值速率：
- 记下当前值 A，等 60 秒再查一次得 B，(B − A) ÷ 60 = MB/s
- 取最近一小时内的最大值，乘以 15–30 分钟（即 900–1800 秒），得到目标总容量
- 若峰值是 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，进程直接退出。
必须按顺序操作：
- 先执行
SET GLOBAL innodb_fast_shutdown = 0，确保所有脏页刷盘、checkpoint 完成 - 用
mysqladmin shutdown或systemctl stop mysql关库，别kill -9 - 确认
ps aux | grep mysqld无残留进程，error log 最后一行是Shutdown complete - 备份旧日志：
cp /var/lib/mysql/ib_logfile* /backup/ - 删干净：
rm /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile1（数量要和innodb_log_files_in_group一致） - 改配置，启动——InnoDB 自动重建日志文件
调大之后还要盯哪几个关键水位
重启后不能就撒手不管。重点观察三个动态值：
-
Log flushed up to和Last checkpoint at的差值，稳定在innodb_log_file_size的 30%–50% 区间才算健康；长期 > 70% 说明还是偏小， -
Innodb_log_waits必须归零，否则说明日志空间仍紧张 - 如果用了
innodb_flush_log_at_trx_commit = 0或= 2，还得确认单秒写入量不超过总日志容量的 1/3，否则断电丢数据风险陡增
真正容易被忽略的是：调大日志后，崩溃恢复时间会变长，但日常提交延迟下降是实打实的；而很多人只盯着“恢复慢”不敢调，却没意识到卡顿本身已在持续损耗业务 SLA。
