MySQL Buffer Pool 怎么在重启后预热常用页

MySQL 重启后想尽快恢复常用数据页，可以启用 InnoDB Buffer Pool 状态保存与恢复：关闭时记录最近使用页的表空间 ID 和页 ID，启动时由后台线程根据这些定位信息重新读取数据页。它不会把整个 Buffer Pool 原样写到磁盘，也不会阻塞数据库完成启动。

我以前遇到过一类很典型的现象：服务重启本身很顺利，但刚恢复流量时，查询延迟和磁盘读取明显高于稳定期。最初我用脚本反复跑几条 SQL“暖库”，结果既难覆盖真实热点，也容易把一次性报表页带进缓存。后来改成 InnoDB 自带的状态保存与恢复，排查思路才变得清楚：先确认有没有可加载的页清单，再观察后台加载是否完成。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/innodb-preload-buffer-pool.html

先判断是不是 Buffer Pool 冷启动

“重启后慢”不一定都由 Buffer Pool 引起。先把现象限定在以下范围：MySQL 已经正常接受连接，执行计划没有突然变化，锁等待和连接数也没有异常，但相同业务查询第一次读取较慢，随后逐步恢复。如果慢查询始终不恢复，或只集中在某一条 SQL，就应继续检查索引、统计信息、锁和存储延迟，而不是只调预热参数。

Buffer Pool 状态恢复解决的是重启后的暖机期。它根据停机前的最近使用页重建一部分缓存，让业务不必完全依赖 DML 首次访问来把页读回内存。官方文档说明加载在后台执行，因此“mysqld 已启动”与“热点页已加载完成”是两个不同状态。

保存的不是内存页，而是页定位信息

状态文件的体积通常远小于 Buffer Pool，因为它保存的是定位页面所需的表空间 ID 与页 ID，而不是页面内容本身。MySQL 8.4 默认把这些信息写入 InnoDB 数据目录下的 ib_buffer_pool 文件，文件名和位置可通过 innodb_buffer_pool_filename 调整。

这一点也解释了为什么数据页在停机后发生正常更新并不会让机制失效：恢复时仍从表空间读取当前页面；如果记录指向的页面已经不存在，加载机制会跳过它。对压缩表，页面先以压缩形式加载，真正访问内容时再按正常路径解压。

先核对三个关键配置

MySQL 8.4 中，innodb_buffer_pool_dump_at_shutdown 与 innodb_buffer_pool_load_at_startup 默认启用，innodb_buffer_pool_dump_pct 默认是 25，也就是保存每个 Buffer Pool 最近使用页中的一部分。即便如此，我仍建议在目标实例上显式核对，而不是假设配置文件没有覆盖默认值。

-- 核对关闭时保存、启动时恢复和保存比例。
SHOW VARIABLES LIKE 'innodb_buffer_pool_dump_at_shutdown';
SHOW VARIABLES LIKE 'innodb_buffer_pool_load_at_startup';
SHOW VARIABLES LIKE 'innodb_buffer_pool_dump_pct';

-- 核对状态文件名，便于后续检查数据目录中的文件。
SHOW VARIABLES LIKE 'innodb_buffer_pool_filename';

如果要把策略固定在配置文件中，可以在 mysqld 使用的配置文件里写入：

[mysqld]
# 关闭时保存最近使用页的定位信息。
innodb_buffer_pool_dump_at_shutdown=ON

# 启动后由后台线程恢复已保存的常用页。
innodb_buffer_pool_load_at_startup=ON

# 保存最近使用页的 25%，先从默认比例开始观察。
innodb_buffer_pool_dump_pct=25

我更倾向于先保留 25%，观察重启后的 I/O 与恢复时长，再决定是否提高。比例越高，写入状态文件的定位项越多，启动后的后台读取量也越大；如果停机前刚跑过一次不典型的大报表，提高比例未必会得到更好的业务热点。

稳定负载后手动刷新状态更可控

除了关机和启动阶段，MySQL 还允许在线保存和恢复 Buffer Pool 状态。对我来说，这个能力最有价值的场景不是日常手工预热，而是在业务达到稳定吞吐后重新保存一次热点页清单，避免一次性维护任务污染停机前的 LRU 状态。

-- 在稳定业务负载后，立即保存当前 Buffer Pool 状态。
SET GLOBAL innodb_buffer_pool_dump_now=ON;

-- 等待保存完成后再安排维护或重启。
SHOW STATUS LIKE 'Innodb_buffer_pool_dump_status';

-- 需要在线重新加载已保存状态时再手动触发。
SET GLOBAL innodb_buffer_pool_load_now=ON;

-- 观察后台加载是否开始、进行中或已经完成。
SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';

不要在 dump 还没完成时就假设文件已经可用。Innodb_buffer_pool_dump_status 会返回未开始、进行中或完成信息；加载对应查看 Innodb_buffer_pool_load_status。这些状态比“配置开关是 ON”更接近真实执行证据。

按证据判断预热有没有真的执行

我把检查拆成三层：配置层确认开关与比例，文件层确认 ib_buffer_pool 的位置和可访问性，进度层确认后台任务确实运行。这样遇到“开关明明是 ON，但重启后还是慢”时，不会一开始就把问题归咎于比例太小。

需要更细进度时，可以启用 Performance Schema 的 Buffer Pool Load stage 事件。它提供已完成页数和估算工作量；任务完成后，events_stages_current 可能返回空集，此时查看历史表。

-- 启用 Buffer Pool Load 的阶段事件采集。
UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES'
WHERE NAME LIKE 'stage/innodb/buffer%';

-- 启用阶段事件消费者，保留当前与历史记录。
UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE '%stages%';

-- 查看正在执行的后台加载进度。
SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED
FROM performance_schema.events_stages_current;

-- 当前表为空时，到历史表确认最近一次是否完成。
SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED
FROM performance_schema.events_stages_history
WHERE EVENT_NAME = 'stage/innodb/buffer pool load';

预热没有达到预期时怎么反向排查

还有一个容易忽略的情况：维护脚本、全表扫描或大型报表会把短期页面带入 LRU。此时预热机制本身可能工作正常，只是保存的“最近使用页”并不是重启后最需要的业务页。与其一味提高比例，我更愿意在稳定业务窗口重新 dump。

最后检查清单

• 确认问题确实是重启后的冷缓存恢复，而不是锁、执行计划或存储故障。
• 核对 dump_at_shutdown、load_at_startup、dump_pct 和 buffer_pool_filename 的实际值。
• 确认 dump_status 已完成，并且状态文件位于 mysqld 可访问的位置。
• 重启后查看 load_status，必要时再启用 Performance Schema stage 进度。
• 加载完成后用业务延迟、磁盘读取和 Buffer Pool 命中趋势判断效果，不只看开关。
• 若热点偏离，先在稳定负载后重新 dump，再谨慎调整保存比例。

这套机制适合希望缩短重启暖机期、又不想维护一套 SQL 预热脚本的 InnoDB 实例。它不是把内存做成持久化快照，也不能替代容量规划和查询优化；它做的是保存一份轻量页清单，让 MySQL 更快找回停机前真正被频繁使用的页。

常见问题

加载 Buffer Pool 会阻塞 MySQL 启动吗？

不会等待所有页面加载完才提供服务。官方文档说明页面由后台线程加载，因此应继续观察 load_status，而不是只看 mysqld 是否已经启动。

ib_buffer_pool 是完整缓存文件吗？

不是。它保存定位页面所需的表空间 ID 与页 ID，真正的数据页仍从表空间读取。

dump_pct 越大越好吗？

不一定。更大的比例意味着更多恢复读取，也更容易包含短期工作负载带来的页面。应结合稳定业务窗口和重启后的实际指标调整。