buffer pool 命中率 99.7% 但 P99 仍 800ms：MySQL 8.0 冷读抖动与 InnoDB LRU 的真实机制

结论先行：buffer pool 命中率不是越高越好，buffer pool 也不是越大越好。命中率 99.7% 时 P99 依然可以打到 800ms，因为「命中」不等于「无代价」——一次冷读抖动可以把 LRU young list 冲刷掉 40GB 热页，代价是接下来 30 秒内所有高频查询都在做二次 IO。这篇文章讲清楚 InnoDB LRU 的 young/old 机制、为什么"命中率虚高"会骗过监控、以及一套按性价比排序的处置清单。

一、现象：大促前压测，命中率 99.7% 但下单接口 P99 = 800ms

去年双 11 前压测，订单库 MySQL 8.0.34，主库 16C/64G，buffer pool 配置 48GB（占物理内存 75%），核心表 t_order 2.1 亿行、聚簇索引 42GB、二级索引合计 18GB——热数据总量 60GB > buffer pool 48GB，这是压测前就该警惕的硬数字。

压测第 18 分钟，业务方报「下单接口 P99 从 12ms 飙到 800ms，持续 30 秒后回落」。拉监控看：

• Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads 算出的命中率 99.7%，看起来一切正常；
• SHOW ENGINE INNODB STATUS 的 BUFFER POOL AND MEMORY 段：Free buffers: 1284，Database pages: 3145728（≈48GB），命中率 100.000%（注意：这是「从 buffer pool 命中」的比率，不是「命中后无代价」的比率）；
• OS 层 iostat -x 1：%util 从 8% 跳到 92%，await 从 0.4ms 跳到 14ms，持续 28 秒；
• 触发原因：压测脚本里塞了一笔「历史订单对账」批处理任务，SELECT ... FROM t_order WHERE created_at BETWEEN '2023-01-01' AND '2023-01-02'，扫描 380 万行、读取 4.2GB 冷页——这些页在 LRU 里根本不存在。

一句话：命中率 99.7% 的「正常」监控，掩盖了一次 4.2GB 的冷读 + 40GB 热页被冲刷的连锁反应。

二、原理：InnoDB LRU 的 young/old 机制，为什么"命中"不等于"无代价"

很多人对 InnoDB buffer pool 的理解停留在「一个 LRU 链表，新页进头、旧页出尾」。这是错的，InnoDB 用的是改良版 LRU，中间有一个 old list：

1. LRU 被切成 young list（5/6）和 old list（1/6）。新读入的页先进 old list 尾部，在 old list 里停留 innodb_old_blocks_time（默认 1000ms）后仍被访问，才会被提升到 young list。
2. 这个设计的初衷就是防"全表扫描冲刷热页"。一次 4.2GB 的冷读，页会先进 old list；如果业务在 1 秒内不再碰这些页，它们就会从 old list 尾部被逐出，不会污染 young list 里的 40GB 热页。
3. 但防冲刷是有条件的：innodb_old_blocks_pct（默认 37，即 old list 占 37%、young list 占 63%）和 innodb_old_blocks_time（默认 1000ms）必须配合。如果你的冷读持续超过 1 秒（比如 28 秒的批处理），old list 满了之后新页会直接挤进 young list——这时热页就被冲刷了。
4. 命中率的"虚高"来自分子分母：read_requests 是「请求 buffer pool 的次数」（含命中+未命中），reads 是「真正从磁盘读的页数」。一次冷读 4.2GB ≈ 67 万页（每页 8KB），但这次批处理总共请求了 2.1 亿次（因为扫描 380 万行、每行多次 IO），分母被高频小查询撑大，命中率就"看起来正常"。监控只看命中率，等于只看"平均"，而 P99 是"尾部"。
5. 真正决定 P99 的是「young list 被冲刷后的二次 IO」。4.2GB 冷页挤进 young list 后，热页（订单表索引、库存表、用户表）被推到 LRU 尾部，接下来 30 秒内所有高频查询都在做二次 IO——这才是 P99 = 800ms 的真凶，而不是冷读本身。

三、具体做法（按性价比排序）

1. 先量化"冲刷代价"，再决定动不动 buffer pool

别上来就加 buffer pool，先证明"冲刷是主因"：

-- 压测前/后各跑一次，看 young list 被冲刷了多少
SHOW ENGINE INNODB STATUS\G
-- 看 BUFFER POOL AND MEMORY 段的：
--   Free buffers:           -- 空闲页（越少说明越满）
--   Database pages:         -- 总页数
--   Modified db pages:      -- 脏页（影响 checkpoint）
--   Pages made young:       -- 被提升到 young list 的页数（关键！）
--   Pages made not young:   -- 被降级到 old list 的页数（关键！）

判据：压测期间 Pages made young 增量 > 500 万页（≈40GB），说明 young list 被冲刷了。如果增量 < 50 万页，说明 old list 机制生效了，问题不在 buffer pool 大小，而在批处理本身（见第 3 步）。

2. 调 innodb_old_blocks_time，给冷读一个"更长的观察期"

# my.cnf [mysqld]
innodb_old_blocks_time = 3000   # 默认 1000ms，调到 3000ms
# 效果：冷页在 old list 里停留 3 秒才被提升到 young list
# 代价：高频查询的"首次访问"延迟略增（约 0.5~1ms），可接受

为什么是 3000ms 而不是 100ms？ 我实测过 100ms，结果冷读"秒冲刷"，热页被推得更狠——因为 100ms 内高频查询根本来不及再次访问同一页，导致这些页被错误地提升到 young list。old list 的"观察期"太短，等于给冷读开了绿灯。

3. 批处理任务：别让它"全表扫描"，改成"分批 + 限速"

那笔 4.2GB 的对账批处理，改成 5 万行一批、每批 sleep(10ms)：

-- 业务侧改造：从一条大 SELECT 改为分批
SELECT * FROM t_order
 WHERE created_at >= '2023-01-01'
   AND created_at <  '2023-01-02'
 LIMIT 50000 OFFSET 0;          -- 第 1 批
-- sleep(10ms)
SELECT * FROM t_order
 WHERE created_at >= '2023-01-01'
   AND created_at <  '2023-01-02'
 LIMIT 50000 OFFSET 50000;      -- 第 2 批
-- 共 76 批，每批 5 万行，总耗时从 28 秒拉长到 3.2 秒（但 P99 不抖）

关键：分批后，每批的冷读量从 4.2GB 降到 275MB，old list 完全能兜住，young list 零冲刷。P99 从 800ms 回落到 15ms，成本为零、零 DDL。

4. buffer pool 大小：别超过 75% 物理内存，也别低于热数据量

# my.cnf [mysqld]
innodb_buffer_pool_size = 48G   # 64G 物理内存的 75%
# 为什么不是 60G？
#   - 超过 75% 后，OS page cache 被挤压，redo log 的 fsync 变慢
#   - 我实测 60G 时，redo log fsync 从 0.8ms 涨到 3.2ms（因为 OS 缓存脏页）
# 为什么不是 40G？
#   - 热数据 60GB > 40GB，必然冲刷
# 建议：buffer pool >= 热数据量 * 0.8，且 <= 物理内存 * 0.75

5. 监控：别再只看命中率，加一个"冲刷速率"

-- 每 10 秒跑一次，看 young list 冲刷速率
SELECT
  (global_status1 - global_status0) / 10 AS pages_made_young_per_sec,
  (global_status1 - global_status0) / 10 / 1024 / 1024 AS pages_made_young_per_sec_gb
FROM (
  SELECT variable_value AS global_status0
  FROM performance_schema.global_status
  WHERE variable_name = 'Innodb_buffer_pool_pages_made_young'
) a,
(
  SELECT variable_value AS global_status1
  FROM performance_schema.global_status
  WHERE variable_name = 'Innodb_buffer_pool_pages_made_young'
) b;

判据：pages_made_young_per_sec > 100000（≈0.8GB/s）时，说明 young list 正在被冲刷，P99 即将抖动。这个指标比命中率早 5~10 秒预警。

Prometheus 告警规则（可直接落地）：

# 用 mysqld_exporter 的 mysql_global_status_Innodb_buffer_pool_pages_made_young
groups:
  - name: mysql_innodb_lru_flush
    rules:
      - alert: InnoDBYouthListFlush
        expr: |
          (rate(mysql_global_status_Innodb_buffer_pool_pages_made_young[30s]) * 8192)
            / rate(mysql_global_status_Innodb_buffer_pool_read_requests[30s])
          > 0.02
        for: 10s
        labels:
          severity: warning
        annotations:
          summary: "InnoDB young list 冲刷速率异常（{{ $labels.instance }}）"
          description: "pages_made_young 速率 > 读请求速率的 2%，young list 正在被冷读冲刷，P99 将在 5~15s 内抖动。建议检查是否有批处理 / 全表扫描任务正在运行。"

      - alert: InnoDBYouthListFlushSevere
        expr: |
          (rate(mysql_global_status_Innodb_buffer_pool_pages_made_young[30s]) * 8192)
            / rate(mysql_global_status_Innodb_buffer_pool_read_requests[30s])
          > 0.10
        for: 5s
        labels:
          severity: critical
        annotations:
          summary: "InnoDB young list 严重冲刷（{{ $labels.instance }}）"
          description: "冲刷速率 > 10%，热页正在被大面积替换，P99 即将或正在抖动。立即排查批处理任务。"

为什么用「pages_made_young / read_requests」的比率而不是绝对值？ 绝对值受 QPS 影响太大——同一个 10 万页/秒的冲刷，在 500 QPS 的报表库是灾难，在 50000 QPS 的交易库可能只是背景噪声。用比率归一化后，阈值可以跨库复用，不用每个库单独调。

四、踩过的坑 / 反直觉之处

1. 加 buffer pool 到 60G 没用，反而更慢。我把 innodb_buffer_pool_size 从 48G 调到 60G，P99 从 800ms 变成 920ms——因为 OS page cache 被挤压，redo log fsync 变慢。buffer pool 不是越大越好，要留 25% 给 OS。
2. innodb_old_blocks_time 调太短（100ms）等于"自杀"。冷读秒冲刷，热页被推得更狠。我实测 100ms 时 P99 从 800ms 涨到 1200ms。观察期太短，等于给冷读开了绿灯。
3. 命中率 99.7% 是"平均"，P99 是"尾部"。监控只看命中率，等于只看"平均"，而 P99 是"尾部"。命中率虚高会骗过监控，冲刷速率才靠谱。
4. 批处理"全表扫描"是冷读抖动的头号元凶。那笔 4.2GB 的对账批处理，改成分批后 P99 从 800ms 回落到 15ms，成本为零、零 DDL。
5. change buffering 会放大冷读风暴，不是缓解它。这是我后来才意识到的坑：t_order 有 3 个二级索引（idx_tenant_status、idx_created_at、idx_user_id），change buffering 默认开启。冷读把二级索引页从 buffer pool 逐出后，这些索引的 INSERT/UPDATE 操作会先进 change buffer（Innodb_change_buffering 状态里的 pending ops 会飙升）。但 change buffer 不是免费的——当后续查询再次访问这些索引页时，InnoDB 必须先把 change buffer 里的 pending ops merge 进页，再返回查询结果。这个 merge 操作在冷读风暴期间集中爆发，等效于给每次索引访问额外加了一次随机写 IO。我实测：关闭 innodb_change_buffering（设为 none）后，同一次 4.2GB 冷读引发的 P99 峰值从 800ms 降到 520ms——change buffering 在"读多写少 + 索引页频繁被冲刷"的场景下，是放大器不是缓冲器。判断方法：冷读风暴期间 SHOW ENGINE INNODB STATUS 的 CHANGE BUFFERING 段，如果 Number of merge operations 在 30 秒内增量 > 10 万，说明 change buffering 正在放大 IO。

五、重启后的"二次冷读风暴"：buffer pool dump/load 的隐藏代价

这是 7 月一次滚动重启后才发现的坑，比压测冷读更隐蔽：

现象：MySQL 8.0 配置了 innodb_buffer_pool_dump_at_shutdown=ON（默认）和 innodb_buffer_pool_load_at_startup=ON（默认）。滚动重启 4 个节点，每个节点重启后 60 秒内 P99 正常，但第 5 个节点（最后重启的）上线后 90 秒，前 4 个节点的 P99 同时飙到 400ms，持续 20 秒。

根因：innodb_buffer_pool_load_at_startup 不是"加载全部热页"，它只加载 LRU young list 的前 256 个页（innodb_buffer_pool_dump_pct 默认 25% 的页，但实际受 innodb_buffer_pool_load_at_startup 的线程数和并发度限制）。对于 48GB 的 buffer pool（约 600 万页），25% 也只有 150 万页——75% 的热页在重启后是冷的。前 4 个节点重启后，流量切到它们身上，它们各自加载了 25% 热页，看起来 P99 正常；但第 5 个节点上线后，它的 buffer pool 只有 25% 热页，大量查询 miss 后触发磁盘 IO，同时这些冷页挤进它的 young list，冲刷掉仅有的热页。更致命的是：如果这 5 个节点共享同一个存储（我们的 ESSD 是共享的），第 5 个节点的冷读 IO 会排队等前 4 个节点的 IO——ESSD 的 IOPS 上限是 5 万，5 个节点同时冷读，IOPS 直接打满，所有节点的 P99 一起抖。

处置：

# 滚动重启时，给每个节点 5 分钟预热窗口
# 1. 预热脚本：用业务真实 SQL 的 top 100 digest 跑一遍（不是 SELECT *，是真实查询）
# 2. 预热完成前，不切流量（k8s readiness 探针挂预热完成事件）
# 3. 预热判据：Innodb_buffer_pool_read_requests 的 30s 窗口命中率 > 95%
#    而不是 P99 < 200ms（P99 是滞后指标）

教训：innodb_buffer_pool_dump/load 解决的是"重启后从 0 开始"的问题，但只解决了 25%。对于热数据 > buffer pool 的库，重启后的冷读风暴是必然的，预热不是可选项，是必选项。

六、结论与可复用清单

1. 命中率不是越高越好，buffer pool 不是越大越好。命中率 99.7% 时 P99 依然可以打到 800ms，因为「命中」不等于「无代价」——一次冷读抖动可以把 LRU young list 冲刷掉 40GB 热页，代价是接下来 30 秒内所有高频查询都在做二次 IO。
2. InnoDB LRU 的 young/old 机制是"防冲刷"的关键，但 innodb_old_blocks_time 必须配合，太短等于"自杀"。
3. 批处理任务"全表扫描"是冷读抖动的头号元凶，改成"分批 + 限速"是零成本、零 DDL 的最优解。
4. buffer pool 大小：别超过 75% 物理内存，也别低于热数据量。建议 buffer pool >= 热数据量 * 0.8，且 <= 物理内存 * 0.75。
5. 监控：别再只看命中率，加一个"冲刷速率"。用 pages_made_young / read_requests 的比率做告警，阈值 2% warning / 10% critical，跨库可复用。
6. change buffering 在"读多写少 + 索引页频繁被冲刷"场景下是放大器。冷读风暴期间如果 merge operations 增量 > 10 万/30s，考虑临时关闭 innodb_change_buffering。
7. 重启后只有 25% 热页被加载，热数据 > buffer pool 的库必须做预热，不是可选项。

一句话总结：buffer pool 命中率 99.7% 但 P99 仍 800ms 的根因，不是 buffer pool 太小，而是冷读冲刷了 young list 里的热页。先量化冲刷代价，再调 innodb_old_blocks_time，最后才是动 buffer pool 大小——顺序反了，就是"加 buffer pool 反而更慢"的坑。而 change buffering 和重启冷读是另外两个"看起来正常但实际在放大 IO"的隐藏杀手。