真实命中率必须用Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads计算：(requests−reads)/requests×100%，因SHOW ENGINE INNODB STATUS中的Buffer pool hit rate仅统计约1000次逻辑读的滑动窗口，瞬时抖动大、不可累加、不能告警。

别信 SHOW ENGINE INNODB STATUS 里的 Buffer pool hit rate

那个值是最近约 1000 次逻辑读的滑动窗口统计，瞬时抖动大、不可累加、不能用于告警。业务一扫大表，它就掉到 800/1000，但缓冲池整体可能完全健康。生产环境必须弃用。

用 SHOW GLOBAL STATUS 算真实命中率

真正该盯的是两个全局状态变量：Innodb_buffer_pool_read_requests（总逻辑读请求数）和 Innodb_buffer_pool_reads（实际磁盘页读次数）。命中率公式是：(requests - reads) / requests * 100%。

• 必须用 SHOW GLOBAL STATUS，SHOW STATUS 会重置计数器
• 推荐单次查完避免时间错位：

  SELECT ROUND((1 - b.Variable_value/a.Variable_value) * 100, 2) AS hit_rate
  FROM performance_schema.global_status a
  JOIN performance_schema.global_status b
    ON a.Variable_name = 'Innodb_buffer_pool_read_requests'
   AND b.Variable_name = 'Innodb_buffer_pool_reads';

• 注意整除陷阱：MySQL 默认整数除法截断，显式转浮点或用 ROUND(, 2)

命中率高 ≠ 缓冲池够用

99.2% 看着漂亮，但如果 Innodb_buffer_pool_reads 每秒稳定在 60+，说明仍有大量热数据没进缓存，或 SQL 在反复回表、排序、全扫描。

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• 先看 Innodb_buffer_pool_reads 的绝对值和每秒增量，不是只盯百分比
• 结合 sys.statement_analysis 查 SUM_ROWS_EXAMINED 高但 SUM_ROWS_SENT 低的语句
• MySQL 8.0.22+ 可用 EXPLAIN FORMAT=JSON 看 disk_reads 字段预估单条语句磁盘压力
• 刚调大 innodb_buffer_pool_size 后要等至少 5 分钟再采——InnoDB 异步 resize，期间 Innodb_buffer_pool_pages_free 持续下降，算出的命中率会失真

扩容前先确认是不是真缺内存

低于 95% 不等于马上加内存。得交叉验证几个信号：

• Innodb_buffer_pool_pages_free 持续为 0？说明已满，但不等于够用（可能频繁淘汰）
• Innodb_buffer_pool_wait_free > 0？说明有线程在等空闲页，必须扩容或优化查询
• Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total 利用率
• 用 free -h 看系统可用内存，innodb_buffer_pool_size 不应超过物理内存的 80%

冷启动后前 30 分钟的数据不准，得等缓冲池“暖”起来再观察趋势——连续 5 分钟 Innodb_buffer_pool_reads 增速明显放缓才算稳。