buffer pool命中率低表明大量请求被迫走磁盘i/o，需结合innodb_buffer_pool_reads/innodb_buffer_pool_read_requests比值（
Buffer Pool命中率低 = 每次查询都在等磁盘
命中率不是个“好看”的指标，而是直接反映InnoDB有没有在用内存干活。当Innodb_buffer_pool_reads（磁盘读）占Innodb_buffer_pool_read_requests（总请求）比例高，说明绝大多数请求没从内存拿到数据，得去磁盘翻页——一次机械盘IO要几毫秒，SSD也要几十微秒，而内存访问是纳秒级。两者差3–5个数量级。你看到的“慢查询”，八成卡在这一步。
99%不是目标，是底线；低于95%就得动手调
命中率计算公式就是：1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests。这不是理论值，是实时运行结果：
- ≥99%：热数据基本稳住，I/O压力轻，可视为健康
- 95%–98%：已有局部冷热失衡，大表JOIN或夜间ETL后容易掉点，建议查
SHOW ENGINE INNODB STATUS里的Buffer pool hit rate和Free buffers - innodb_buffer_pool_size设小了，或者业务突然加载了新数据集但没预热，物理读暴增，
iostat -x 1里%util常飙到95%+
别只看size，Buffer Pool实际可用内存比配置值少
innodb_buffer_pool_size写的是“申请多少”，但OS、MySQL线程栈、其他进程、甚至Buffer Pool内部控制块都会吃掉一部分。比如你配了32G，在128G物理内存机器上看似合理，但若系统已跑Java服务占20G+，再开swap或触发OOM Killer，mysqld反而被杀。真实可用缓冲池 ≈ 配置值 × 0.92–0.95（控制块开销约5%–8%）。
更关键的是：Buffer Pool不是越大越好。超过物理内存70%且未预留足够OS空间时，Linux会开始swap，此时哪怕命中率显示99%，响应延迟也会因页换入换出剧烈抖动——这种“伪高命中”最骗人。
命中率突然下跌？先盯这三个地方
不是所有命中率下降都该调size。先快速排除常见诱因：
- 执行了全表扫描类SQL（如
SELECT * FROM huge_table），LRU链表被冲刷，热数据被踢出——查information_schema.PROCESSLIST找长耗时查询 - 大批量导入/更新触发脏页刷盘竞争，
Innodb_buffer_pool_pages_dirty持续高位，Free List枯竭，新读请求被迫等刷盘——看SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free'是否非零 - Buffer Pool实例数太少（
innodb_buffer_pool_instances默认1），高并发下所有线程争抢同一LRU链表锁——8核以上建议设为8或16
真正需要调innodb_buffer_pool_size的时候，永远是“命中率持续偏低 + Free buffers长期接近0 + 磁盘IOPS顶满”三者同时出现。单看一个数字就加内存，容易把问题从I/O瓶颈变成内存争用瓶颈。
