脏页刷新会卡住sql，因为：1. redo log写满时所有更新被阻塞；2. 内存不足淘汰脏页需同步刷盘；3. 刷脏页触发邻接页“连坐”刷新，放大io延迟。

脏页刷新为什么会卡住你的 SQL？

MySQL 执行一条更新语句时，通常只改内存页 + 写 redo log，立刻返回成功。但当它突然“抖”一下、响应变慢，大概率正在同步脏页——也就是把内存里已修改但还没落盘的数据页写进磁盘。

这个过程本身不慢，但会阻塞后续操作：

• 如果是 redo log 写满触发的刷脏页，所有更新请求会被直接挂起，直到 checkpoint 推进、空间腾出；
• 如果是内存不足触发的刷脏页，查询或更新在申请新页时，发现要淘汰的页是脏页，就得当场等它刷完才能复用内存；
• 刷脏页不是单页操作，InnoDB 有“连坐”逻辑：刷一个脏页时，若相邻页也是脏页，会一并刷掉，可能拖慢整个流程。

哪些场景最容易让你的 SQL 中招？

真正影响线上性能的，只有两类刷脏页行为：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

• redo log 空间太小，比如设成 100MB（而不是常规的 4×1GB），高峰期很快写满，write pos 追着 checkpoint 走，系统反复停写、推进、再停写；
• 缓冲池（innodb_buffer_pool_size）配置过小，或业务突增导致脏页比例长期高于 75%，内存不够用时频繁淘汰脏页；
• 大查询（如全表扫描）加载大量非热点数据页进内存，挤占空间，间接逼出一批脏页要刷；
• innodb_io_capacity 值远低于磁盘真实 IOPS，让 InnoDB “不敢”刷快，积压越久，单次刷得越猛。

怎么确认是不是脏页在捣鬼？

别猜，看指标：

• 查 SHOW ENGINE INNODB STATUS\G，重点关注 BACKGROUND THREAD 下的 flushed 数和 pages made young；
• 监控 Innodb_buffer_pool_pages_dirty 和 Innodb_buffer_pool_pages_flushed，如果后者突增且伴随 QPS 下跌，基本就是它；
• 观察磁盘 IO：刷脏页时 iostat -x 1 会看到 %util 飙高、await 拉长，但 redo log 写满时反而磁盘 IO 很低（因为写被堵死了）；
• 检查错误日志里有没有类似 Waiting for query cache lock 或 Waiting for redo log space 的等待记录（注意：后者不会明写，但结合 show status like 'Innodb_os_log_pending_fsyncs' > 0 可佐证）。

调参时最容易忽略的三个细节

很多人调了参数却没效果，问题常出在这些地方：

• innodb_io_capacity 必须匹配物理磁盘能力，SSD 一般设 2000–4000，HDD 别超过 200；设太高会让 InnoDB 过度刷盘，抢走业务 IO；
• innodb_max_dirty_pages_pct 默认 75，但如果你用的是高写入负载+低延迟要求的场景，建议压到 50–60，避免批量刷页；
• innodb_log_file_size 不是越大越好，总大小（× 文件数）建议控制在 1–2 小时的写入量内；太大 recovery 慢，太小则频繁刷脏页。

真正难处理的，是那种“刷脏页本身不慢，但连坐范围不可控”的情况——你没法预测哪一页的邻居也脏，更没法阻止它蔓延。这时候光调参没用，得结合业务节奏做削峰，比如错开定时任务与高峰写入。