buffer pool监控需综合页使用率、磁盘读绝对值和脏页比例三维度：用show global status查pages_data/pages_total是否持续>95%、innodb_buffer_pool_reads每秒是否超20次、dirty页是否持续上升，而非仅依赖命中率。
Buffer Pool使用情况不能只看一个“命中率”，得同时盯住三件事：它是不是被填满了、有没有大量数据反复进出、磁盘读压力到底有多大。光调大innodb_buffer_pool_size不解决问题，反而可能挤占其他关键内存。
怎么查Buffer Pool当前用了多少页
最直接的方式是用SHOW GLOBAL STATUS查页级状态，不是靠计算百分比猜：
-
Innodb_buffer_pool_pages_total：总页数（固定值，重启后不变） -
Innodb_buffer_pool_pages_data：已存数据的页数（含索引页） -
Innodb_buffer_pool_pages_free：完全空闲页数 -
Innodb_buffer_pool_pages_dirty：修改过但未刷盘的脏页数
注意：Innodb_buffer_pool_pages_data ≠ “有效缓存”——它包含压缩页、自适应哈希索引页等，实际可用空间会略低。别用pages_free == 0判断“已满”，而要看pages_data / pages_total是否持续 > 95%，且pages_free长期为个位数。
为什么命中率高但性能还在掉
常见错觉：看到hit_rate > 99%就以为没问题。其实Innodb_buffer_pool_reads这个绝对值才是关键：
- 如果每秒
Innodb_buffer_pool_reads稳定在 20+，说明每秒都有20+次磁盘随机读——哪怕命中率99.8%，I/O压力依然存在 - 命中率公式是
(1 - reads / requests) * 100，但requests可能因批量查询、全表扫描虚高，掩盖真实热数据覆盖不足 - 配合
SHOW ENGINE INNODB STATUS\G里BUFFER POOL AND MEMORY段的Pages read（累计读入）和Pages created（新分配），若前者远大于后者，说明大量页被反复淘汰重载，LRU链表抖动严重
Buffer Pool碎片和chunk对齐怎么影响监控
MySQL 5.7+把Buffer Pool拆成多个innodb_buffer_pool_instances，每个instance又由若干innodb_buffer_pool_chunk_size（默认128MB）组成。这意味着：
- 你设
innodb_buffer_pool_size = 4000M，实际分配可能是4096MB——因为要按chunk_size × instances向上对齐 -
SHOW GLOBAL STATUS里的页数统计是全局汇总，但底层各instance负载可能不均；单看总命中率会掩盖某个instance频繁驱逐的问题 - 在线resize（
SET GLOBAL innodb_buffer_pool_size = ...）是以chunk为单位增减，过程中会短暂锁住部分LRU链表，高并发下可能引发瞬时卡顿，别在业务高峰执行
该用哪个SQL查才准，别踩子查询时间错位坑
别写带子查询的SELECT (1 - (SELECT ... FROM performance_schema.global_status WHERE ...)) * 100——两个VARIABLE_VALUE可能取自不同时间点，结果失真。正确做法是用SHOW GLOBAL STATUS一次性获取：
mysql> SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%read%';
或者用CROSS JOIN确保原子性：
SELECT ROUND((1 - r.reads / req.requests) * 100, 2) AS hit_rate FROM (SELECT VARIABLE_VALUE + 0 AS reads FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') r CROSS JOIN (SELECT VARIABLE_VALUE + 0 AS requests FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests') req;
加+ 0是为了强制类型转换，避免字符串比较出错；performance_schema.global_status比INFORMATION_SCHEMA.GLOBAL_STATUS更新更及时，优先选前者。
真正难的是把pages_data、reads、dirty三个维度的变化趋势画在同一张图上——上升的脏页比例+下降的命中率+缓慢增长的free页，往往意味着写入突增或刷盘线程跟不上，这时候光看单点数值根本发现不了问题。
