innodb_log_waits持续增长是最直接信号，说明innodb_log_buffer_size过小导致事务提交前被迫等待刷盘；需结合innodb_os_log_written速率（×2～3为buffer下限）和show engine innodb status中log差值交叉验证，并配平innodb_flush_log_at_trx_commit等参数。
看 Innodb_log_waits 是否持续增长
这是最直接的信号：只要这个值非零且随时间上升，说明 innodb_log_buffer_size 已经不够用，事务在提交前被迫等待 buffer 刷盘。它不是“偶尔抖动”，而是稳定爬升——比如每分钟涨 5～10，基本可以锁定是 buffer 太小。
查法很简单：SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';，隔 30 秒再查一次，差值大于 0 就要干预。
注意：Innodb_log_waits 增长 ≠ 磁盘慢，90% 情况下只是内存 buffer 没攒够批就溢出了，跟磁盘 I/O 本身关系不大。
算 Innodb_os_log_written 的写入速率
这个状态变量记录的是累计写入 redo log 的字节数。拿它做差值，就能算出真实写入压力：
- 执行两次
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_os_log_written';，间隔 10 秒 - 差值 ÷ 10 得到 MB/s（例如从 120GB → 124GB，差值为 4GB = 4096MB，速率就是 409.6 MB/s）
- 把这个速率 × 2～3，就是
innodb_log_buffer_size的合理下限（如 409.6 MB/s → 至少设 1024MB）
别只看峰值；要取业务高峰期连续 5 分钟的平均速率，否则调完还是压不住。
观察 SHOW ENGINE INNODB STATUS\G 中的 Log section
重点盯三个字段：
-
Log sequence number：当前已生成的日志位置 -
Log flushed up to：已刷到磁盘的日志位置 -
Last checkpoint at：上一次 checkpoint 刷脏页的位置
如果 Log sequence number 和 Log flushed up to 差值长期 > 1GB，或者 Log checkpoint age（即前者减后者）占总 redo log 容量的 70% 以上，说明日志系统整体承压——但根源往往不在磁盘，而在 buffer 没攒够、或 innodb_log_file_size 太小导致 checkpoint 频繁触发。
此时再结合 Innodb_log_waits 和写入速率交叉验证，就能分清是 buffer 卡住、还是文件容量卡住、还是刷盘策略太激进。
确认 innodb_flush_log_at_trx_commit 是否与场景错配
这个参数决定日志何时真正落盘，直接影响写入吞吐和数据安全边界：
- 设为
1：每次 commit 都fsync，最安全，但极易成为瓶颈（尤其机械盘或高并发小事务） - 设为
2：commit 只写 OS cache，每秒刷盘一次；性能提升明显，但主机断电会丢最多 1 秒数据 - 设为
0：完全交由后台线程刷，风险最高，仅限测试环境
线上误用 1 是常见坑——不是所有表都需要强持久。日志表、埋点表、统计中间表完全可以设为 2；但只要有一张表涉及资金、订单、用户余额，整个实例就不能设为 2 或 0，否则 binlog 和 redo log 无法对齐，主从复制可能断裂。
查法：SELECT @@innodb_flush_log_at_trx_commit;；改之前务必确认业务容忍度，别只看监控数字。
真正难的不是调参，而是把 innodb_log_buffer_size、innodb_log_file_size、innodb_flush_log_at_trx_commit 三者配平——buffer 太大而 file 太小，照样触发频繁 checkpoint；file 调大却不改 flush 策略，buffer 再大也白搭。每次只动一个参数，等于没动。
