必须确认innodb_buffer_pool_dump_at_shutdown已启用，否则升级后首次启动时innodb_buffer_pool_load_at_startup将因无ib_buffer_pool文件而静默失效，导致buffer pool冷启动、命中率低、延迟飙升；该参数只读，须在旧版my.cnf的[mysqld]段配置并重启生效。
升级前必须确认 innodb_buffer_pool_dump_at_shutdown 是否已启用
MySQL 升级（尤其是跨大版本，如 5.7 → 8.0 或 8.0 → 9.6）本身不改变 buffer pool 预热逻辑，但升级过程常伴随配置重载、实例重启甚至 datadir 迁移。若 innodb_buffer_pool_dump_at_shutdown 未在旧版本中开启，升级后首次启动时 innodb_buffer_pool_load_at_startup 就会静默失败——因为根本没有 ib_buffer_pool 文件可读。
检查方式很简单：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'innodb_buffer_pool_dump_at_shutdown';
返回 ON 才算有效；若为 OFF 或空，说明上次正常关闭时没 dump，升级重启后 buffer pool 仍是冷的。
- 该参数是只读的，
SET GLOBAL不生效，必须在旧版my.cnf的[mysqld]段中显式配置并重启过一次才能落地 - 常见漏点：配置写在
[client]段、容器部署未挂载正确配置、升级脚本覆盖了原有my.cnf - 即使你已在新版本配置了
load_at_startup=ON，只要旧实例没 dump 过，它就毫无作用
升级后首次启动时 load_at_startup 失效的典型表现
升级完成、mysqld 启动成功，但业务一上来延迟飙升、Innodb_buffer_pool_reads 持续高位，Innodb_buffer_pool_read_requests 命中率长期低于 90%，这就是预热没生效的信号。
不要只看 SHOW STATUS LIKE 'Innodb_buffer_pool_load_status' —— 它可能显示 completed，但那只是“尝试加载完毕”，不代表页真进来了。更准的验证方式是：
- 查
information_schema.INNODB_BUFFER_POOL_STATS中的pages_data值：升级前记下数值，启动后 2 分钟内应快速接近或超过该值 - 执行
SELECT * FROM information_schema.INNODB_BUFFER_PAGE LIMIT 5（仅调试），确认热点表的SPACE是否大量出现（需配合INNODB_SYS_TABLES映射） - 观察
SHOW ENGINE INNODB STATUS\G输出里的Buffer pool hit rate，稳定在 99%+ 才算真正暖起来
升级中无法依赖 dump_at_shutdown 的场景及补救
升级流程若包含强制 kill、崩溃重启、或使用 mysqld --initialize 重建系统表空间，innodb_buffer_pool_dump_at_shutdown 就完全失效——因为关机 dump 根本没触发。
此时唯一可靠手段是升级后立即手动预热：
- 先执行
SET GLOBAL innodb_buffer_pool_dump_now = ON，生成当前 buffer pool 快照（注意：这步在升级后首次启动后做，不是升级前） - 等
Innodb_buffer_pool_dump_status显示完成，再立刻执行SET GLOBAL innodb_buffer_pool_load_now = ON - 若想聚焦核心表，可人工过滤
ib_buffer_pool文件（路径由innodb_buffer_pool_filename决定），只保留关键SPACE对应的行，再触发 load - 避免用
SELECT *全表扫：它不保页、易被淘汰、还可能被 purge 干扰，对预热无效
MySQL 9.6+ 特别注意 container_aware 与预热路径权限
2026 年发布的 MySQL 9.6 引入了 container_aware 启动选项，默认启用。它会自动调整 datadir 路径解析逻辑，但可能导致 innodb_buffer_pool_filename 实际落盘位置与预期不符——比如从 /var/lib/mysql/ib_buffer_pool 变成 /var/lib/mysql/data/ib_buffer_pool。
升级到 9.6 后务必验证：
-
SHOW VARIABLES LIKE 'innodb_buffer_pool_filename';返回的路径，MySQL 进程是否有写权限？ - 升级后首次正常关闭，是否真在该路径下生成了非空的
ib_buffer_pool文件？ - 若用 Docker，确认该路径已声明为 volume 并正确挂载，否则容器销毁后文件丢失
预热不是配置开就完事，关键是 dump 和 load 两个动作在升级前后能否真正串起来——中间断一环，buffer pool 就得靠业务请求慢慢“熬”热，而高并发场景下这一熬就是几分钟的性能洼地。
