InnoDB 脏页到底什么时候刷盘？一文彻底讲透 Flush List 与 Checkpoint 机制
在上一篇文章中，我们已经搞清楚了一件事：
InnoDB 并不是“随便刷盘”，而是通过 Flush List 精准管理所有脏页。
但紧接着，一个更现实、也是 DBA 在生产中最关心的问题就来了：
❓ 这些 Flush List 里的脏页，到底什么时候刷盘？谁来刷？一次刷多少？
今天这篇文章，我们就继续深入 InnoDB 内核，把Flush List → 刷盘 → Checkpoint这条完整链路彻底讲清楚。
一、先说结论：刷盘不是“想刷就刷”
很多人对 MySQL 的理解还停留在：
“后台线程会慢慢把脏页刷回磁盘”
但在真实的生产环境中，如果刷盘策略设计不好，结果只有两个：
- ❌ IO 打满，TPS 暴跌
- ❌ 脏页堆积，崩溃恢复时间爆炸
所以 InnoDB 对刷盘这件事的核心目标只有一句话：
在不影响前台业务的前提下，尽可能均匀、可控地刷脏页。
而这正是Checkpoint 机制存在的意义。
二、Flush List 中的脏页，并不会立刻刷盘
先明确一个重要事实：
缓存页一旦变脏，只是“有资格刷盘”，并不代表“马上刷盘”。
Flush List 的作用只是：
- 记录：哪些页被修改过
- 标记：这些页“迟早要写回磁盘”
是否刷、什么时候刷，由刷盘触发条件决定。
三、InnoDB 触发刷盘的 4 个核心时机（DBA 必须知道）
1️⃣ Buffer Pool 空间不足（最危险）
当数据库需要新的缓存页，但：
- free list 里已经没有空闲页
- LRU 淘汰出来的页，恰好是脏页
这时怎么办？
👉只能先刷盘，再复用缓存页
这类刷盘的特点是：
- 非常被动
- 容易造成 IO 突刺
- TPS 会明显下降
📌DBA 提示
如果你在监控中看到：
- Buffer Pool free pages 很少
- IO 使用率突然升高
很可能就是这种情况。
2️⃣ 后台定期刷盘（最健康）
InnoDB 内部有专门的后台线程（page cleaner）：
- 周期性检查 Flush List
- 按照算法刷一部分脏页
- 目标是：“提前消化脏页”
这类刷盘的特点：
- 平滑
- 可预测
- 对业务影响最小
这也是最理想的刷盘方式。
3️⃣ Checkpoint 推进（核心机制）
这是最关键、也是 DBA 必须理解的部分。
什么是 Checkpoint？
简单说一句人话：
Checkpoint 表示：redo log 中，哪些修改已经安全落盘。
- Checkpoint 之前的 redo log
👉 对应的脏页必须已经刷盘 - Checkpoint 之后的 redo log
👉 允许还没刷盘
为什么 Checkpoint 一定会触发刷盘？
因为 redo log 是有限大小的。
当 redo log 快要写满时：
- 如果 Checkpoint 不往前推进
- redo log 就无法继续写
- 前台事务会被阻塞
于是 InnoDB 只能：
👉强制刷一批 Flush List 中的脏页
👉推进 Checkpoint
这也是为什么：
redo log 太小，一定会导致性能问题
4️⃣ 数据库关闭或崩溃恢复
- 正常 shutdown：
→ 尽量刷干净脏页 - 崩溃恢复：
→ redo log 重放 + 脏页修复
这类场景我们不展开，DBA 更关注前 3 种。
四、Flush List + Checkpoint 的协同关系（重点）
可以用一句话概括它们的关系：
Flush List 管“刷谁”，Checkpoint 管“刷到哪一步算安全”。
换个更形象的比喻：
- Flush List：
👉 一份“待办刷盘任务清单” - Checkpoint：
👉 一条“安全线”，线前的数据必须已落盘
InnoDB 的所有刷盘策略，本质上都是在：
控制 Flush List 的长度 + 控制 Checkpoint 推进速度
五、为什么“脏页太多”会拖垮数据库？
这是生产中非常经典的问题。
当 Flush List 过长时，会发生什么？
- Checkpoint 推进变慢
- redo log 空间被持续占用
- 最终触发强制刷盘
- IO 飙升，TPS 下降
- 延迟抖动，业务超时
你会看到：
- 数据库 CPU 不高
- SQL 本身也不慢
- 但 TPS 就是上不去
📌根因往往是：刷盘失控
六、DBA 实战建议（非常重要）
✅ 1. Buffer Pool 要足够大
原则：
Buffer Pool 能兜住“业务高峰期的脏页量”
否则：
- 脏页来不及刷
- 被动刷盘频繁触发
✅ 2. redo log 不能太小
redo log 太小的直接后果是：
- Checkpoint 频繁推进
- 刷盘压力集中爆发
这是很多系统：
“低并发还行，一上并发就抖”的根本原因之一。
✅ 3. 重点关注这些指标
DBA 日常必须盯的：
- Buffer Pool dirty pages
- Flush List length
- redo log 使用率
- page cleaner 活跃度
- 磁盘 IO latency
这些指标，比单纯看 QPS 有价值得多。
七、一句话 DBA 总结
Flush List 决定“哪些页需要刷”，Checkpoint 决定“刷到哪里才算安全”，两者共同决定了 MySQL 的性能上限与稳定性下限。
理解这一套机制，你就真正从：
- “会用 MySQL”
- 迈进了
👉“懂 MySQL 内核的 DBA”