Buffer Pool命中率低主因是缓存污染、未预热、参数未配对或宽索引反模式；需结合30分钟后长期命中率、youngs/s及pages_data/total_pages比值交叉验证，并通过高频表索引分析与unused_indexes筛查定位问题。
Buffer Pool命中率低，八成不是因为innodb_buffer_pool_size设得太小，而是缓存被污染、预热没做、参数没配对，或者索引设计反模式——尤其在MySQL 5.7上，刚重启后看一眼SHOW ENGINE INNODB STATUS\G里的Buffer pool hit rate就下结论，基本等于没查。
怎么确认是不是真低？别信单个数字
MySQL 5.7 的 Buffer pool hit rate（比如显示 856 / 1000）是滚动 1秒窗口的瞬时值，抖动极大。刚重启后前10分钟基本不准，Innodb_buffer_pool_reads会暴增，Innodb_buffer_pool_read_requests还没稳定，算出来可能只有70%。
- 真正该盯的是：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';，用公式(Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100算出的长期命中率，等至少30分钟再看 - 同时查
SHOW ENGINE INNODB STATUS\G中BUFFER POOL AND MEMORY段的youngs/s：低于 10 表明大量页刚进缓存就被淘汰，大概率是缓存污染 - 再跑
SELECT pages_data, pages_total FROM information_schema.INNODB_BUFFER_POOL_STATS;，如果pages_data / pages_total ，说明缓存根本没吃饱，不是“太小”，而是“没用上”
为什么innodb_buffer_pool_size调大了反而更糟？
MySQL 5.7 要求 innodb_buffer_pool_size 必须是 innodb_buffer_pool_instances × 128MB 的整数倍。设了个 48G，但 innodb_buffer_pool_instances = 5，5 × 128MB = 640MB，48G ÷ 640MB = 76.8 → 非整数，MySQL 启动时会自动向下截断，实际生效可能只有 47.5G，且 chunk 对齐失败会在错误日志里打 warning，但不报错。
- 检查是否生效：执行
SHOW VARIABLES LIKE 'innodb_buffer_pool%';，确认innodb_buffer_pool_size和innodb_buffer_pool_instances值与配置文件一致 - 推荐起步值：
innodb_buffer_pool_instances = 8或12，对应 size 取 48G → 48G ÷ 128MB = 384，384 ÷ 8 = 48，刚好整除 - instances 设太高（比如 32）会让每个 instance 太小，LRU 局部性变差，冷热混杂更严重；设太低（比如 1）高并发下锁争用明显，页加载延迟升高
宽索引和全表扫描才是隐形杀手
一个 INDEX (a,b,c,d,e) 被查询只用前两列，InnoDB 还是得把整页索引数据读进来；回表时再拉一次聚簇索引页——两个页都占 Buffer Pool，但只有第一个页的部分内容被访问。这种低频页塞满缓存，直接拉低 youngs/s 和命中率。
- 查污染源：
SELECT * FROM performance_schema.table_io_waits_summary_by_table WHERE COUNT_READ > 100000 ORDER BY COUNT_READ DESC LIMIT 5;找出高频读表，再查information_schema.STATISTICS看是否建了 ≥5 列的二级索引 - 验证冗余：
EXPLAIN FORMAT=JSON SELECT ...看输出里key_parts和used_columns是否严重不匹配 - 删之前先筛闲置索引：
SELECT * FROM sys.schema_unused_indexes WHERE selectivity = 0 AND last_update ，这类可直接 <code>DROP INDEX
预热没做，等于每天重来一遍冷启动
Buffer Pool 启动时空的，所有查询都触发磁盘读。没有预热，命中率要靠业务自然“暖库”，可能花几小时甚至一两天才爬升到正常水平——这期间慢查询、超时、连接堆积全来了。
- MySQL 5.7 支持
innodb_buffer_pool_dump_at_shutdown = ON和innodb_buffer_pool_load_at_startup = ON，重启后自动加载上次 dump 的热点页 - dump 文件默认存
ib_buffer_pool，路径由innodb_buffer_pool_filename控制，确保 MySQL 有写权限 - 手动触发预热：
SELECT COUNT(*) FROM t1 JOIN t2 USING (id) WHERE ...这类语句慎用，容易把冷数据也刷进来；优先用SELECT id FROM t WHERE id BETWEEN ? AND ?这种覆盖主键范围的轻量查询
最难的从来不是改参数，而是判断哪些页该留、哪些该赶出去——这得靠 EXPLAIN FORMAT=JSON 看真实访问路径，靠 performance_schema 看实际 IO 分布，靠重启后半小时的 youngs/s 和 pages_data / pages_total 交叉验证。光调大 innodb_buffer_pool_size 不碰索引和预热，就像往漏水桶里拼命灌水。
