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

作者陈星河

MySQLbuffer poolInnoDBP99冷读抖动DBA

结论先行：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：

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

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

加 buffer pool 到 60G 没用，反而更慢。我把 innodb_buffer_pool_size 从 48G 调到 60G，P99 从 800ms 变成 920ms——因为 OS page cache 被挤压，redo log fsync 变慢。buffer pool 不是越大越好，要留 25% 给 OS。
innodb_old_blocks_time 调太短（100ms）等于"自杀"。冷读秒冲刷，热页被推得更狠。我实测 100ms 时 P99 从 800ms 涨到 1200ms。观察期太短，等于给冷读开了绿灯。
命中率 99.7% 是"平均"，P99 是"尾部"。监控只看命中率，等于只看"平均"，而 P99 是"尾部"。命中率虚高会骗过监控，冲刷速率才靠谱。
批处理"全表扫描"是冷读抖动的头号元凶。那笔 4.2GB 的对账批处理，改成分批后 P99 从 800ms 回落到 15ms，成本为零、零 DDL。

五、结论与可复用清单

命中率不是越高越好，buffer pool 不是越大越好。命中率 99.7% 时 P99 依然可以打到 800ms，因为「命中」不等于「无代价」——一次冷读抖动可以把 LRU young list 冲刷掉 40GB 热页，代价是接下来 30 秒内所有高频查询都在做二次 IO。
InnoDB LRU 的 young/old 机制是"防冲刷"的关键，但 innodb_old_blocks_time 必须配合，太短等于"自杀"。
批处理任务"全表扫描"是冷读抖动的头号元凶，改成"分批 + 限速"是零成本、零 DDL 的最优解。
buffer pool 大小：别超过 75% 物理内存，也别低于热数据量。建议 buffer pool >= 热数据量 * 0.8，且 <= 物理内存 * 0.75。
监控：别再只看命中率，加一个"冲刷速率"。pages_made_young_per_sec > 100000 时，P99 即将抖动。

一句话总结：buffer pool 命中率 99.7% 但 P99 仍 800ms 的根因，不是 buffer pool 太小，而是冷读冲刷了 young list 里的热页。先量化冲刷代价，再调 innodb_old_blocks_time，最后才是动 buffer pool 大小——顺序反了，就是"加 buffer pool 反而更慢"的坑。

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。