从库预热不能只靠主库buffer pool转储，因dump仅在关闭时触发且从库长期运行；load index into cache可精准加载索引页；基于慢日志+pt-query-digest重放高频查询更贴近真实访问；切换前需手动stop slave→dump→load→start slave并校验状态。
从库预热为什么不能只靠主库 Buffer Pool 转储
因为 innodb_buffer_pool_dump_at_shutdown 只在关闭时触发，而从库通常不主动 shutdown —— 它可能长期运行、只在切换前临时提升为新主库。此时它的 Buffer Pool 是“冷”的，但转储文件仍是旧的（甚至不存在），直接启动加载无效。
常见错误现象：Innodb_buffer_pool_load_status 显示 “not started” 或加载页数为 0；切换后 Innodb_buffer_pool_reads 突增，查询延迟明显。
- 从库一般不配置
innodb_buffer_pool_load_at_startup=ON，默认不加载转储文件 - 即使启用了，若上次 dump 是几天前，加载的页可能早已不是当前热点
- 主库 dump 的页 ID 在从库上不一定对应相同数据（尤其主从延迟大或表结构变更后）
用 LOAD INDEX INTO CACHE 预热核心索引页
这是最可控、低风险的从库预热方式，适用于已知业务高频访问的表和索引。它不依赖历史 dump 文件，也不触发大量数据页读取，只加载 B+ 树顶层和中间层页，内存开销小、速度快。
使用场景：主从切换前 5–10 分钟，或定期维护窗口内执行。
- 仅对 InnoDB 表生效，MyISAM 不支持
- 语法必须指定索引名，
LOAD INDEX INTO CACHE hot_order (PRIMARY, idx_user_id) - 若省略索引名，默认加载所有索引（含二级索引），可能浪费内存
- 执行后可通过
SHOW STATUS LIKE 'Key_blocks_used'观察索引缓存变化
基于慢日志 + pt-query-digest 构建精准预热 SQL
比盲扫全表更高效，也比单纯加载索引更贴近真实访问模式。核心是提取从库最近 24 小时的慢查询（或高频查询），重放其 WHERE 条件，触发对应数据页加载。
示例流程：
- 开启从库慢日志：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; - 用
pt-query-digest分析日志，提取 top 20 查询模板 - 对每个模板做轻量级执行（加
LIMIT 100，避免扫描全表）：SELECT id, status FROM order WHERE user_id IN (1001,1002,...) LIMIT 100; - 避开高峰期执行，单次预热控制在 30 秒内，防止阻塞复制 SQL 线程
切换前手动触发 buffer pool dump 并立即加载
这是唯一能复用 InnoDB 原生 warmup 机制的方式，但必须在切换动作前主动干预，不能依赖自动行为。
关键步骤顺序不能错：
- 先暂停从库复制：
STOP SLAVE; - 立即 dump 当前热点：
SET GLOBAL innodb_buffer_pool_dump_now = ON;（注意：该命令返回即开始 dump，无需等待） - 确认 dump 完成：
SHOW STATUS LIKE 'Innodb_buffer_pool_dump_status';看到 “Dump completed” - 立刻加载：
SET GLOBAL innodb_buffer_pool_load_now = ON; - 再
START SLAVE;恢复同步（此时 Buffer Pool 已部分热）
容易被忽略的是：dump 和 load 都是异步操作，SET 命令返回不代表完成；必须用 SHOW STATUS 查状态，否则可能误判预热效果。
