Buffer Pool 预热不能靠 SELECT * 扫全表，因其按需读取、不保页、易被淘汰；真正有效的是基于 space_id+page_no 的页级加载，如 innodb_buffer_pool_dump_now + load_now 或启动时自动 load_at_startup。
Buffer Pool 预热为什么不能靠 SELECT * 扫全表？
直接执行 SELECT * 扫描冷表，看似能“触发”数据页加载，但实际效果极差：InnoDB 会按需读取、逐页解压（如果启用了页压缩）、校验 checksum，并可能被 purge 线程或并发 DML 干扰；更关键的是，SELECT 不保证页留在 Buffer Pool 中——一旦 LRU 链表发生淘汰，刚读进来的页立刻被踢出。预热失败的典型表现是：查询延迟没降，Innodb_buffer_pool_read_requests 增长快，但 Innodb_buffer_pool_reads（物理读）下降不明显。
真正有效的预热必须绕过 SQL 解析与优化器路径，直接让 InnoDB 将指定 page 加载进 Buffer Pool 并保留在 LRU old 区以上位置。MySQL 官方从 5.7 开始提供 innodb_buffer_pool_load_at_startup 和配套工具，这才是正路。
用 innodb\_buffer\_pool\_dump\_now + load\_now 实现可控预热
这是最轻量、最可控的线上预热方式，不依赖配置重启，适用于突发流量前手动触发：
- 先用
SELECT * FROM information_schema.INNODB_BUFFER_PAGE LIMIT 10确认当前 Buffer Pool 里已有哪些热点表/索引页（注意：该表性能开销大，仅调试用；生产建议用innodb_buffer_pool_dump_now） - 执行
SET GLOBAL innodb_buffer_pool_dump_now = ON—— 立即触发 dump，生成文件默认在datadir/ib_buffer_pool，格式为 “space_id:page_no” 每行一条 - 确认 dump 完成后（查
SHOW STATUS LIKE 'Innodb_buffer_pool_dump_status'），可人工过滤该文件，只保留你关心的表对应 space_id（用SELECT SPACE, NAME FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE 'db_name/table_name%'查） - 执行
SET GLOBAL innodb_buffer_pool_load_now = ON—— InnoDB 会读取ib_buffer_pool文件，异步将对应 page 加载进 Buffer Pool，且优先保留在 LRU new 区
注意：innodb_buffer_pool_load_now 是一次性操作，不会持续监听文件变化；若需周期性预热，得配合定时任务重 dump + load。
启动时自动预热：配置 innodb\_buffer\_pool\_load\_at\_startup
适合稳定业务场景，MySQL 启动时自动加载上次 dump 的页面。但有三个硬约束必须满足：
-
innodb_buffer_pool_dump_at_shutdown必须为ON（默认 OFF），否则关机前不会 dump，启动时就无数据可 load -
innodb_buffer_pool_load_at_startup设为ON（默认 OFF），且该参数只能在配置文件中设置，启动后无法动态开启 - dump 文件路径由
innodb_buffer_pool_filename控制，默认ib_buffer_pool，确保 MySQL 进程对该路径有读写权限，否则启动日志会出现[Warning] InnoDB: Cannot open ./ib_buffer_pool
该机制本质是把“预热时机”从运行时转移到了启动阶段，对首次冷启动有效，但对运行中 Buffer Pool 被大量刷空（如大事务回滚、内存压力）无效——它不解决运行时热点失效，只解决“每次重启都冷”的问题。
用 mysqlpump 或 mysqldump --single-transaction 预热是误区
有人尝试用逻辑导出命令“顺便”读一遍数据，这反而有害：
-
mysqldump --single-transaction会开启长事务，占用 undo log、阻塞 purge，还可能拉长锁等待链 -
mysqlpump默认并行导出，多个线程争抢 Buffer Pool LRU，容易把真实业务热页挤出去 - 导出结果是逻辑行，不是物理页；InnoDB 仍要走聚簇索引查找、二级索引回表等完整路径，无法跳过解析和执行计划生成
真正需要预热的是物理存储结构：B+ 树非叶节点、聚簇索引叶页、常用二级索引页。只有基于 space_id + page_no 的页级加载，才能精准命中、最小扰动、最大收益。
预热不是“多读几遍”，而是“读对位置”。别碰 SELECT SLEEP(1) 循环扫主键，也别信“加个 FORCE INDEX 就能稳住缓存”——Buffer Pool 管理权在 InnoDB 内部，外部 SQL 只能触发，不能指挥。
