I
Member
业务高峰时 MySQL 写入延迟突然上去，读都还正常，别先加机器，按下面顺序定位，大概率是刷盘链路先顶不住。
一、先看延迟长在哪。写入延迟分三段：应用到数据库的网络、InnoDB 的 redo 写、刷盘落盘；用 performance_schema 或慢日志看等待事件，先把锅分到某一段，别上来就调参数。
二、查 redo log。redo log 写满触发 checkpoint 时，写入会被迫等刷盘；看 checkpoint age 和 log 占用比例，如果高峰期长期贴近上限，redo log 偏小或刷盘太慢都有可能，先分清是容量还是速度问题。
三、查刷盘策略。innodb_flush_log_at_trx_commit 和 sync_binlog 的组合直接决定每次提交要不要等落盘；改之前先确认业务能不能接受对应级别的丢失窗口，别为了延迟把持久性偷偷降了档。
四、查磁盘本身。iostat 看 await 和 util，高峰期 util 长期满格说明盘先到了瓶颈；再看是不是和备份、日志归档、其他实例抢了同一块盘，错峰或分盘往往比调参数见效快。
五、留好对照。把高峰期的 TPS、延迟、checkpoint age、磁盘 await 记成一组，改完参数再跑同一时段对照，别凭感觉说“好像快了”。
你们遇到写入延迟突增，最后查出来是 redo、刷盘策略还是磁盘本身的问题多？
一、先看延迟长在哪。写入延迟分三段：应用到数据库的网络、InnoDB 的 redo 写、刷盘落盘；用 performance_schema 或慢日志看等待事件，先把锅分到某一段，别上来就调参数。
二、查 redo log。redo log 写满触发 checkpoint 时，写入会被迫等刷盘；看 checkpoint age 和 log 占用比例，如果高峰期长期贴近上限，redo log 偏小或刷盘太慢都有可能，先分清是容量还是速度问题。
三、查刷盘策略。innodb_flush_log_at_trx_commit 和 sync_binlog 的组合直接决定每次提交要不要等落盘；改之前先确认业务能不能接受对应级别的丢失窗口，别为了延迟把持久性偷偷降了档。
四、查磁盘本身。iostat 看 await 和 util，高峰期 util 长期满格说明盘先到了瓶颈；再看是不是和备份、日志归档、其他实例抢了同一块盘，错峰或分盘往往比调参数见效快。
五、留好对照。把高峰期的 TPS、延迟、checkpoint age、磁盘 await 记成一组，改完参数再跑同一时段对照，别凭感觉说“好像快了”。
你们遇到写入延迟突增，最后查出来是 redo、刷盘策略还是磁盘本身的问题多？