缓冲池命中率低于95%表明物理读过多，需结合slow_query_log中Rows_examined远大于Rows_sent、SHOW ENGINE INNODB STATUS中Buffer pool hit rate及innodb_buffer_pool_reads/innodb_buffer_pool_read_requests比值综合判断，排除冷启动干扰后持续偏低则说明配置失配或存在全表扫描。
查慢查询日志里有没有大量全表扫描
物理读飙升时，slow_query_log 里往往伴随大量 SELECT 语句被记录，且 Rows_examined 值远高于返回行数（比如查10行却扫了10万行）。这不是SQL写得差，而是缓存没兜住——数据页根本没进 innodb_buffer_pool，每次都要从磁盘硬读。
打开慢日志（确认 slow_query_log = ON，long_query_time = 1），用 mysqldumpslow -s t -t 10 /var/log/mysql/slow.log 看最耗时的前10条。如果其中多数语句都带 Using where; Using filesort 或 Using temporary，再结合 SHOW ENGINE INNODB STATUS\G 里的 Buffer pool hit rate（低于 99% 就危险），基本能锁定是缓冲池太小。
看 SHOW GLOBAL STATUS 里两个关键计数器比值
innodb_buffer_pool_reads 是每秒从磁盘读取页的次数，innodb_buffer_pool_read_requests 是每秒逻辑读请求总数。真正要盯的是它们的比值：1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)
- 低于 99.0%：明显不足，开始出现“缓存抖动”
- 低于 95.0%：已严重失配，物理IO成瓶颈
- 高于 99.5%：当前配置基本健康
别只看单次查询慢——持续 5 秒内该比值反复跌破 98%，就说明 innodb_buffer_pool_size 没撑住热数据集。注意：这个比值在刚启动 MySQL 后会偏低，等缓存预热 10–20 分钟再测。
检查错误日志里是否出现 Cannot allocate memory 或 InnoDB initialization failed
当 innodb_buffer_pool_size 设得过大（比如 128G 机器设了 100G），MySQL 启动时可能直接失败，错误日志里会出现：
2026-07-02T07:20:14.123456Z 0 [ERROR] InnoDB: Cannot allocate 107374182400 bytes of memory
或者更隐蔽的：
2026-07-02T07:21:03.678910Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
这类报错不是数据库“慢”，而是压根起不来或运行中被 OOM Killer 杀掉。此时必须立刻查系统内存：free -h 看可用内存是否长期 dmesg -T | grep -i "killed process" 确认 mysqld 是否被干掉。不要只改 MySQL 配置——先降 innodb_buffer_pool_size，再关掉非必要服务腾内存。
验证修改后参数是否真正生效
改完 my.cnf 里的 innodb_buffer_pool_size = 4G，重启 MySQL，但 SHOW VARIABLES LIKE 'innodb_buffer_pool_size' 返回的还是旧值？常见原因有：
- 配置文件路径不对：MySQL 实际加载的是
/etc/my.cnf，你改了/usr/etc/my.cnf - 单位写错：
innodb_buffer_pool_size = 4000M（合法） vsinnodb_buffer_pool_size = 4000MB（无效，会被忽略） - 被其他配置覆盖：检查是否有
!includedir引入了冲突的 conf 文件 - 未重启服务：
systemctl restart mysqld才生效，mysqladmin reload不管用
最稳的验证方式：重启后执行 SELECT @@innodb_buffer_pool_size;，结果必须和配置值一致（单位是字节），否则配置没生效，别急着调优。
真正麻烦的不是算不准百分比，而是把 innodb_buffer_pool_size 当成孤立参数调——它和 max_connections、sort_buffer_size 共享同一块物理内存。一个调大，另一个就得缩，否则总内存超限，系统比数据库先崩。
