缓冲池命中率需手动计算，公式为(innodb_buffer_pool_read_requests - innodb_buffer_pool_reads) / innodb_buffer_pool_read_requests，反映逻辑读中免磁盘i/o的比例；低于95%需警惕，但须排除冷启动干扰，并结合innodb_buffer_pool_reads增量、慢查询等综合判断。
怎么看 innodb_buffer_pool_read_requests 和相关指标
缓冲池命中率不是 MySQL 直接提供的一个现成数值，得自己算。核心是用两个状态变量：读请求总数 Innodb_buffer_pool_read_requests（从缓冲池读取的逻辑次数），和实际物理读次数 Innodb_buffer_pool_reads（缓冲池没命中、不得不从磁盘读的次数）。
执行这条 SQL 就能拿到最新值：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%read%';
注意别漏掉 GLOBAL，会话级状态里没有这些计数器。返回结果里重点关注这两行：
-
Innodb_buffer_pool_read_requests：越大说明查询越频繁，但单看它没意义 -
Innodb_buffer_pool_reads：这个值持续上涨，才真正提示缓存不够用
命中率怎么算？别被分母搞错
公式是：(Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests。本质是「逻辑读中免于磁盘 I/O 的比例」。
常见错误是把 Innodb_buffer_pool_reads 当成分母——那是错的，那只是失败次数，不是总请求量。
举个例子：如果 Innodb_buffer_pool_read_requests = 1000000，Innodb_buffer_pool_reads = 5000，那命中率就是 (1000000 - 5000) / 1000000 = 99.5%。低于 95% 就该警惕了。
小提示：用 SELECT 算比在应用层拼接更稳，避免浮点精度或整除陷阱：
SELECT (a.Variable_value - b.Variable_value) / a.Variable_value AS hit_ratio FROM information_schema.GLOBAL_STATUS a, information_schema.GLOBAL_STATUS b WHERE a.Variable_name = 'Innodb_buffer_pool_read_requests' AND b.Variable_name = 'Innodb_buffer_pool_reads';
为什么刚启动时命中率低？别急着调参
MySQL 启动后缓冲池是空的，所有第一次访问的数据页都得从磁盘加载，Innodb_buffer_pool_reads 会猛增，命中率可能跌到 0%。这是正常冷启动现象，不代表配置有问题。
判断是否真有问题，得看「稳定运行几小时后」的数值趋势。观察方法：
- 每 5 分钟查一次，连续记 30 分钟，看
Innodb_buffer_pool_reads增速是否明显放缓 - 对比业务低峰期和高峰期的命中率变化幅度——如果高峰时暴跌 20%，才值得深挖
- 注意
Innodb_buffer_pool_wait_free是否非零，那是缓冲池淘汰压力大的信号
命中率高 ≠ 没问题：几个容易被忽略的盲区
命中率只反映「页级读」是否走缓存，掩盖了不少真实瓶颈：
- 全表扫描多的话，
Innodb_buffer_pool_read_requests会虚高——大量页被读入又很快淘汰，命中率好看但 I/O 压力不减 - 写密集场景下，
Innodb_buffer_pool_pages_dirty高 + 刷脏慢，会导致后续读被迫等刷盘，这时命中率可能不低，但响应延迟上去了 -
innodb_buffer_pool_size设得太大，超出物理内存，触发系统 swap，反而让整体性能断崖下跌
真正要盯的，不是单个数字，而是 Innodb_buffer_pool_reads 的绝对增量 —— 如果每秒稳定高于 50，且 innodb_buffer_pool_size 已占内存 70% 以上，那大概率是索引缺失或查询没走索引，得去看慢日志了。
