建议设为75，兼顾热数据覆盖率与dump文件大小；热数据分布稳定可压至50，波峰业务宜保持75～90；默认25偏保守，需配合手动触发验证效果。
innodb_buffer_pool_dump_pct 设置多少才不浪费也不丢热数据
这个参数控制每次 INNODB_BUFFER_POOL_DUMP_NOW 或自动 dump 时，只保存缓冲池中最热的前 N% 页面。设得太低（比如 25），可能漏掉刚升温但还没进前 25% 的关键热页；设得太高（比如 100），dump 文件体积暴涨，重启加载慢，还可能把临时热点（如某次大查询扫出的冷表页）也固化进去。
生产环境建议从 75 起步，观察 dump 文件大小和后续 INNODB_BUFFER_POOL_LOAD_NOW 加载耗时。若实例热数据分布稳定（比如固定几个大表高频访问），可压到 50；若业务有明显波峰（如每小时批量任务触发新热点），建议保持 75～90。
- 默认值是
25，对多数中高负载 mysql 实例偏保守 - 修改后不会立即生效，需配合手动触发或等待下一次自动 dump（由
innodb_buffer_pool_dump_at_shutdown或定时事件触发） - dump 文件本身不压缩，
innodb_buffer_pool_dump_pct=90可能使ib_buffer_pool文件比50时大 2～3 倍
为什么设置了 innodb_buffer_pool_dump_at_shutdown 还没生成 ib_buffer_pool 文件
这个开关只是“允许在 shutdown 时 dump”，不是“保证每次 shutdown 都 dump”。真正触发 dump 还要满足两个隐性条件：缓冲池必须已初始化完成、且至少有一页被真正使用过（空实例或刚启动还没执行任何查询的实例不会 dump）。
更常见的失败原因是权限问题：mysqld 进程必须对 datadir 目录有写权限，且不能被 SELinux/AppArmor 拦截。错误日志里如果出现 Failed to open file 'ib_buffer_pool' 或 Operation not permitted，基本就是它。
- 检查是否真有页面被缓存：执行
select count(*) FROM information_schema.INNODB_BUFFER_PAGE;，结果为 0 就不会 dump - 确认
datadir路径：用SELECT @@datadir;查，然后手动ls -ld看属主和 SELinux 上下文 -
innodb_buffer_pool_dump_now是即时触发命令，比依赖 shutdown 更可控，适合验证配置是否生效
ib_buffer_pool 文件加载失败的典型报错和对应解法
最常遇到的是 Buffer pool load skipped because of invalid file format or permission issue。这不是语法错误，而是 MySQL 在启动时读取 ib_buffer_pool 后发现内容与当前实例不兼容：比如文件是 MySQL 5.7 生成的，但你用 8.0 启动；或者文件里记录的 page_id 已不存在（表被删了、表空间被重建过）。
另一个隐蔽问题是时间戳校验：MySQL 会对比 ib_buffer_pool 文件 mtime 和 ibdata1 的修改时间，若前者更新，直接跳过加载——这在用备份恢复后容易发生。
- 删除旧
ib_buffer_pool并手动触发一次SET GLOBAL innodb_buffer_pool_dump_now=ON;，再关库重启 - 升级 MySQL 版本后务必清空原有
ib_buffer_pool，不同版本 page 格式不兼容 - 用
stat ib_buffer_pool和stat ibdata1对比修改时间，必要时touch ib_buffer_pool
用 innodb_buffer_pool_load_at_startup 加速冷启动，但实际效果不明显
这个参数开启后，MySQL 启动时会异步预热 ib_buffer_pool 里的页面，但它只负责“发起读取请求”，不保证这些页一定留在缓冲池里。如果启动后立刻有大量新查询涌入，刚预热的页可能马上被挤出去——尤其当 innodb_buffer_pool_size 设置偏小、或并发连接数远超预期时。
另外，预热是顺序读取 ib_buffer_pool 文件并逐页发起 I/O，对 SSD 影响不大，但在机械盘上可能拖慢整体启动速度，反而得不偿失。
- 确认是否真在加载：查
SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';，状态为Buffer pool(s) load completed at ...才算走完流程 - 预热期间
Innodb_buffer_pool_read_requests会突增，但Innodb_buffer_pool_reads（物理读）未必下降，说明页又被淘汰了 - 比起依赖预热，更有效的是控制启动后流量爬升节奏，比如用 LB 权重逐步放开，给缓冲池 1～2 分钟“沉淀”时间
热数据持久化不是开几个开关就完事的事——ib_buffer_pool 文件本质是快照，而热数据本身是流动的。参数调得再准，也架不住业务逻辑突然改写访问模式，或者某张表的数据量一夜之间涨十倍。所以定期看 INNODB_BUFFER_POOL_STATS 里的 pages_data/pages_dirty 比例、结合慢查分析哪些表真正在吃缓冲池，比死磕某个百分比重要得多。