Innodb_log_waits归零且checkpoint间隔稳定在15分钟以上最可靠；前者非零说明redo log容量不足，后者过短（1–5分钟）表明刷盘压力大，需协同调优buffer pool、binlog及磁盘I/O。
直接看 Innodb_log_waits 是否归零、SHOW ENGINE INNODB STATUS\G 中 checkpoint 间隔是否稳定在 15 分钟以上，这两个指标比 QPS 提升更可靠。
用 Innodb_log_waits 判断日志容量是否仍不足
该状态变量非零，说明事务被迫等待 redo log 空间释放，是容量瓶颈最直接的证据。升级后若仍持续增长，哪怕 QPS 上去了，本质仍是“带病运行”。
- 每秒执行
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits'，连续观察 5 分钟，值保持为0才算过关 - 若出现非零值（如
1或更高），说明新容量仍无法缓冲峰值写入，需进一步扩大innodb_redo_log_capacity或检查刷盘是否被阻塞 - 注意：该值不会自动清零，需人工记录差值；重启后重置，但不能作为健康依据
从 SHOW ENGINE INNODB STATUS\G 抓 checkpoint 实际周期
日志切换不是靠配置推算，而是看实际触发频率。高负载下每 1–5 分钟一次 checkpoint 是危险信号，目标是拉长到 15–30 分钟且波动小。
- 执行命令后，在
LOG段找Last checkpoint at和当前Log sequence number，两者差值除以写入速率（Innodb_os_log_written差值 ÷ 时间）即得剩余缓冲时长 - 若差值长期低于总容量的 30%，说明 checkpoint 太激进；若长期高于 90%，可能因
innodb_max_dirty_pages_pct过低或刷盘线程跟不上 - 不要只看单次结果——连续采样 3 次，间隔 60 秒，看趋势是否收敛
对比升级前后 innodb_os_log_written 的写入速率与突刺幅度
单纯看吞吐提升没意义，关键看写入是否更平滑。高频小突刺比低频大突刺更伤稳定性。
- 用
pt-mysql-summary或自建脚本每 10 秒抓一次Innodb_os_log_written，画出 1 小时曲线图 - 升级前常见“锯齿状”尖峰（每几分钟一次陡升），升级后应变为缓坡+小幅毛刺
- 若突刺幅度未降（如仍频繁冲到 200MB/s+），要排查是否
innodb_flush_log_at_trx_commit被设为1且磁盘 fsync 延迟高，或 binlog 与 redo log 共用慢盘
别漏掉 innodb_redo_log_capacity 的生效验证
MySQL 8.0.30+ 支持动态调大该参数，但不等于立刻生效——它只控制后台分配上限，实际文件大小由后续 checkpoint 触发扩容，过程不可见。
- 执行
SET GLOBAL innodb_redo_log_capacity = 4294967296后，立刻查SELECT * FROM performance_schema.innodb_redo_log_files（8.0.33+）或看错误日志是否有Redo log resizing to记录 - 若 10 分钟内无扩容日志，说明当前脏页压力不够，需人工触发一次大事务或批量插入来“挤出”空间需求
- 扩容完成前，
innodb_redo_log_capacity值只是“天花板”，真实可用容量仍为旧值
真正难的是把“日志不等待”和“checkpoint 不抖动”同时稳住——前者靠容量，后者靠刷盘节奏与磁盘响应能力。很多调参失败，其实是把 redo log 当成孤立模块，忽略了它和 buffer pool 刷脏、binlog 组提交、甚至文件系统 barrier 设置的耦合关系。
