buffer pool命中率低需先确认innodb_buffer_pool_hit_rate真实值（过去60秒加权平均，999=99.9%），查show engine innodb status\g中buffer pool and memory段；低于900（90%）需结合qps判断，持续
Buffer Pool 命中率低，先看 innodb_buffer_pool_hit_rate 真实值
MySQL 的 innodb_buffer_pool_hit_rate 并不是实时百分比，而是过去 60 秒的加权平均（单位是“每千次请求命中次数”），所以看到 999 不代表 99.9%，而是 99.9%；看到 950 实际是 95.0%。很多人误判就卡在这儿。
查法必须用：
SHOW ENGINE INNODB STATUS\G
然后在 BUFFER POOL AND MEMORY 段里找 Buffer pool hit rate 行——SHOW VARIABLES 或 information_schema 里的视图不反映实时波动。
- 低于 900（即 90%）要警惕，但得结合 QPS 看：低流量下偶尔掉到 850 可能只是冷启动抖动
- 如果稳定在 700 以下，大概率是 Buffer Pool 太小，或查询严重缺乏索引导致频繁刷页
-
Pages read ahead高 +Pages flushed高，说明预读和刷脏页竞争激烈，光调大小没用，得先优化慢查询
分配多少内存给 innodb_buffer_pool_size 才不算浪费
不是越大越好，也不是照搬“物理内存 70%”这种笼统建议。关键看 innodb_buffer_pool_pages_total 和 innodb_buffer_pool_pages_data 的比值。
执行：
SELECT VARIABLE_VALUE AS total_pages FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_total';<br>SELECT VARIABLE_VALUE AS data_pages FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_data';
如果 data_pages / total_pages ，说明长期有大量空闲页，当前配置可能已够用，再扩意义不大。
- 线上 OLTP 业务，优先保证
data_pages占比 ≥ 0.85，再考虑是否扩容 - 单实例多租户场景，避免设到 80% 以上——Linux OOM Killer 可能先杀 mysqld
- 容器环境必须显式限制
--memory，否则innodb_buffer_pool_size超限会导致容器被 kill，错误日志里只有Killed process，没有 MySQL 错误码
热点数据进不来 Buffer Pool？检查 innodb_old_blocks_pct 和访问模式
InnoDB 默认把新读入的页放在 LRU 链表的“old”区域（占整个链表 37%），防止全表扫描这类一次性访问污染热数据。但如果你的应用是周期性刷新报表、定时汇总，这些“伪热点”反而会把真实热点挤出去。
典型症状：innodb_buffer_pool_read_requests 高，innodb_buffer_pool_reads 也高，但 innodb_buffer_pool_pages_misc（管理页）占比异常高，说明 LRU 链表碎片化严重。
- 确认是否真有周期性大查询：抓
slow_log里Rows_examined突增的语句 - 临时缓解可调低
innodb_old_blocks_pct到 5–10（默认 37），但仅适用于明确知道访问局部性强的场景 - 更稳妥的做法是：对高频点查加
SQL_NO_CACHE（不推荐）或改用覆盖索引，让数据从索引页直接返回，减少对主键页的依赖
重启后命中率归零？别急着调大 Buffer Pool
Buffer Pool 冷启动是常态，但“恢复慢”往往不是因为大小，而是加载策略太保守。MySQL 8.0.22+ 支持 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup，但默认只 dump 最近访问的页，且加载是后台异步进行的。
问题常出在：innodb_buffer_pool_dump_pct 默认 25，意味着只保存 1/4 的热页；而 innodb_buffer_pool_load_at_startup 启动时加载速度受 innodb_io_capacity 限制，不是越快越好。
- 生产环境建议设
innodb_buffer_pool_dump_pct = 75，确保核心热页落盘 - 避免在高峰期执行
SET GLOBAL innodb_buffer_pool_dump_now = ON，会触发全量扫描 LRU 链表，CPU 尖刺明显 - 如果用的是 MySQL 5.7，没有自动 load 功能，只能靠
SELECT * FROM table WHERE id IN (…)主动预热，但注意别锁表——用WHERE id % 100 = 1分批轻量触发
Buffer Pool 的“调优”本质是数据访问模式的映射，不是内存数字游戏。最常被忽略的一点：当 innodb_buffer_pool_pages_free 长期为 0，但命中率仍上不去，问题八成不在池子大小，而在 SQL 是否真的需要这么多数据页——先看执行计划，再动配置。
