当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 8.4 Buffer Pool 预热实战：重启后 P99 为什么突然飙高

MySQL 8.4 Buffer Pool 预热实战：重启后 P99 为什么突然飙高

来源：17golang MySQL频道原创 2026-06-04 14:52:41 0浏览收藏

先说结论：重启后的慢，不一定是 SQL 变差，可能是 Buffer Pool 变冷

MySQL 重启后，有些接口突然 P99 飙高，过十几分钟又慢慢恢复。很多人第一反应是看 CPU、连接池、慢 SQL，但真正原因可能很朴素：InnoDB Buffer Pool 里的热点页没了，查询需要重新从磁盘把数据页和索引页读回来。

MySQL 8.x 提供了 Buffer Pool dump/load 能力，用来在关闭前记录热点页，在启动后加载这些页，缩短冷启动窗口。但这不是万能按钮。生产里还要配合业务热点预热、IO 观察和重启演练。

MySQL Buffer Pool 预热思维导图 — Buffer Pool 预热要同时看参数、业务热点 SQL、IO 压力和恢复时间。

业务场景：发布重启后订单详情接口抖了 20 分钟

一次常见场景是：数据库维护窗口内重启，启动后应用连接恢复，业务看起来可用，但订单详情、用户首页、库存查询的 P99 明显升高。过一段时间后，延迟自然回落。

这类现象通常伴随：

Innodb_buffer_pool_reads 在启动后短时间明显上升。
磁盘 IOPS 和读延迟比平时高。
慢 SQL 样本并不固定，很多热点 SQL 都变慢。
缓存热起来后问题自然缓解。

先查参数：dump/load 是否按预期启用

先看和 Buffer Pool dump/load 相关的参数：

SHOW VARIABLES LIKE 'innodb_buffer_pool_dump%';
SHOW VARIABLES LIKE 'innodb_buffer_pool_load%';

MySQL 8.4 常见配置会启用关闭时 dump 和启动时 load，并通过 innodb_buffer_pool_dump_pct 控制 dump 热页比例。不要盲目把比例调到 100，热点页太多会拉长启动恢复过程，也会和业务流量抢 IO。

SET GLOBAL innodb_buffer_pool_dump_now = ON;
SET GLOBAL innodb_buffer_pool_load_now = ON;

SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';

MySQL Buffer Pool 冷启动诊断流程 — 我会先确认 dump/load，再做业务热点预热，最后用指标判断是否稳定。

别把预热脚本写成全表扫描

很多团队一听预热，就写一个脚本把大表扫一遍。这很危险。预热的目标是把真正的热点索引页和数据页带回内存，不是制造一次新的全库压测。

我更喜欢从慢日志、SQL 统计和业务访问路径里挑 TOP SQL，做轻量回放：

-- 订单详情热点索引预热
SELECT id
FROM orders
WHERE paid_at >= NOW() - INTERVAL 1 DAY
ORDER BY paid_at DESC
LIMIT 5000;

-- 用户近期活跃数据预热
SELECT id
FROM users
WHERE updated_at >= NOW() - INTERVAL 6 HOUR
ORDER BY updated_at DESC
LIMIT 5000;

这些 SQL 只拿少量列，尽量走已有索引，按批次执行，并且在每批之间留出间隔。预热脚本本身也要限流，否则它会和刚恢复的业务流量抢磁盘。

MySQL Buffer Pool 预热参数和 SQL 案例 — 预热脚本要短、轻、可控，只覆盖真实热点路径。

诊断指标：命中率不是唯一答案

Buffer Pool 命中率可以看，但不要只看一个百分比。冷启动阶段我更关心趋势：物理读是否快速回落，P99 是否回到基线，磁盘队列是否消失。

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
SHOW GLOBAL STATUS LIKE 'Innodb_data_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_load_status';

如果 Innodb_buffer_pool_reads 长时间高位，说明大量页仍然从磁盘读取。此时要结合慢 SQL 看是不是某些新热点没被 dump 覆盖，还是预热脚本范围选错了。

踩坑原因：dump_pct 不是越大越好

innodb_buffer_pool_dump_pct 控制 dump 热页的比例。比例太小，启动后仍然要从业务流量里慢慢热起来；比例太大，load 阶段可能拖慢启动并增加 IO 压力。我的做法是从默认值或较保守比例开始，通过重启演练记录恢复时间和 P99 曲线，再决定是否调整。

如果你的实例 Buffer Pool 很大，比如几百 GB，尤其不要拍脑袋调大。预热是一种恢复策略，不是把所有内存内容完整搬回来。

上线检查：重启演练要包含业务流量

我会把数据库重启演练拆成几个可观测阶段：

重启前手动触发一次 dump，确认状态完成。
启动后观察 load 状态和 IO。
按批执行热点 SQL 预热，观察 P99 是否回落。
对比重启前后的 TOP SQL、物理读和磁盘延迟。
记录从 mysqld 可连接到业务延迟稳定的总时间。

只有这个流程跑过，你才知道维护窗口要预留多久，以及自动扩容、故障切换、版本升级后会不会出现冷启动抖动。

个人经验：预热要服务业务，而不是服务指标

我见过有人为了让命中率好看，把大表扫一遍，结果业务刚恢复就被预热脚本拖慢。预热的目标不是立刻把命中率打满，而是让关键接口先稳定。订单、库存、登录、支付这些路径优先级更高，低频报表可以慢慢热。

另一个经验是别忽略应用侧缓存。数据库 Buffer Pool 冷，应用本地缓存、网关缓存、热点查询限流也要一起配合。单靠 MySQL 参数，很难把重启后的第一波冲击完全吃掉。

总结

MySQL 8.x 的 Buffer Pool dump/load 能明显缩短冷启动窗口，但它需要工程化落地：参数确认、热点 SQL 预热、IO 限流、指标观察和重启演练。重启后 P99 飙高时，先查物理读和 Buffer Pool 状态，再判断是不是 SQL 真变慢。把热数据温柔地请回内存，比把全库硬扫一遍靠谱得多。