Buffer Pool 命中率 =（1−Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests）×100%，应长期保持在 95% 以上；低于 90% 需关注，持续低于 85% 表明存在严重性能瓶颈。
Buffer Pool 是 InnoDB 存储引擎的核心内存结构，它缓存磁盘上的数据页（如表数据、索引页），避免频繁读写磁盘。命中率高，说明多数查询直接从内存获取数据；命中率低，则大量请求被迫回刷磁盘，性能明显下降。
Buffer Pool 命中率怎么算？
命中率 = (1 − Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) × 100%
其中：
- Innodb_buffer_pool_read_requests：逻辑读请求数（即 SQL 查询尝试从 Buffer Pool 获取页的次数）
- Innodb_buffer_pool_reads：物理读次数（当 Buffer Pool 没有目标页时，从磁盘读取并加载进内存的次数）
建议长期维持在 95% 以上。低于 90% 就需关注，持续低于 85% 往往意味着严重瓶颈。
为什么 命中率会低？常见原因
不是内存小就一定命中率低，关键看“用得是否合理”。常见问题 包括：
- Buffer Pool 总大小设置过小，无法容纳活跃数据集（比如热数据 > 10GB，但只配了 2GB）
- 存在全表扫描或大范围索引扫描，一次性加载大量冷数据页，挤出热页（LRU 链表被污染）
- 大量短连接执行未加索引的查询，反复触发随机 I/O，且不复用页
- innodb_old_blocks_pct 设置不当（默认 37），导致预读页或临时访问页过早进入热区，驱逐真正 热点 页
- 没有启用 innodb_buffer_pool_dump_at_shutdown 和 restore_at_startup，重启后冷启动命中率为 0
提升命中率的实操建议
优化不是一味加内存，而是让有限内存服务真正需要的数据：
- 根据实际热数据规模设置 innodb_buffer_pool_size：通常设为物理内存的 50%–75%，但需预留足够内存给 OS 和其他进程
- 检查慢查询日志，重点优化缺失索引、导致全表扫描的 SQL；用 EXPLAIN 确认是否走了索引、是否扫描过多行
- 对高频小查询，考虑使用覆盖索引减少回表，降低对主键页的访问压力
- 若业务有明显读写分离或批量导入场景，可调大 innodb_old_blocks_time（如设为 1000ms），让非热点页更难进入热区
- 开启自动保存 / 恢复：设置 innodb_buffer_pool_dump_at_shutdown=ON 和 innodb_buffer_pool_load_at_startup=ON，加速重启后暖机
如何持续监控和验证效果？
别只看单次结果，要观察趋势：
- 用 SHOW ENGINE INNODB STATUSG 查看当前 Buffer Pool 状态段，重点关注“Buffer pool hit rate”行（注意：该值是最近 60 秒滑动窗口，参考性有限）
- 更可靠方式：定期采集 SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool_%’ 的数值，计算分钟级 / 小时级命中率变化
- 结合 information_schema.INNODB_BUFFER_POOL_STATS（MySQL 5.7+）查看各 instance 的使用分布，确认是否存在不均衡
- 配合 pt-buffer-pool-analysis 等 工具 分析页访问模式，识别长期驻留页 vs 频繁进出页
