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

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

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

MySQL 8.x 提供了 Buffer Pool dump/load 能力，用来在关闭前记录热点页，在启动后加载这些页，缩短冷启动窗口。但这不是万能按钮。生产里还要配合业务热点预热、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';

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

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

我更喜欢从慢日志、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 只拿少量列，尽量走已有索引，按批次执行，并且在每批之间留出间隔。预热脚本本身也要限流，否则它会和刚恢复的业务流量抢磁盘。

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

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 真变慢。把热数据温柔地请回内存，比把全库硬扫一遍靠谱得多。