排查MySQL缓存需先确认版本，5.7及以下检查query_cache_type、size及Qcache_lowmem_prunes指标，过高则调优或关闭；重点分析InnoDB缓冲池命中率，确保innodb_buffer_pool_size合理设置，结合慢查询日志与EXPLAIN优化执行计划，避免全表扫描，8.0以上无需关注查询缓存，应聚焦buffer pool与索引优化。
排查 MySQL 缓存问题需要从多个方面入手，尤其是关注查询缓存（Query Cache）、InnoDB 缓冲池（Buffer Pool）以及操作系统层面的缓存。虽然新版 MySQL（8.0+）已移除查询缓存，但如果你使用的是 5.7 或更早版本，仍需注意这部分的影响。
检查是否启用了查询缓存
在 MySQL 5.7 及以下版本中，查询缓存可能成为性能瓶颈，特别是当写操作频繁时。
- 运行 SHOW VARIABLES LIKE 'query_cache_type'; 查看是否开启（ON/OFF/DEMAND）
- 查看 SHOW VARIABLES LIKE 'query_cache_size'; 确认分配大小
- 通过 SHOW STATUS LIKE 'Qcache%'; 分析命中率：
- Qcache_hits：缓存命中次数
- Qcache_inserts：插入缓存的查询数
- Qcache_lowmem_prunes：因内存不足清理的条目，数值高说明缓存不够用或碎片严重
如果 Qcache_lowmem_prunes 频繁增长，说明缓存频繁被淘汰，可能是 size 设置过小或缓存机制本身效率低下。建议在高并发写场景下关闭 query_cache_type = OFF。
分析 InnoDB 缓冲池使用情况
InnoDB Buffer Pool 是主要的数据和索引缓存区域，直接影响读性能。
- 查看配置：SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; 建议设置为物理内存的 50%~70%
- 监控命中率：SHOW ENGINE INNODB STATUS; 查看 BUFFER POOL AND MEMORY 部分
- 关注 Buffer pool hit rate，理想应高于 95%
- 通过状态变量进一步分析：
- SHOW STATUS LIKE 'Innodb_buffer_pool_read%';
- 计算命中率：(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100%
若命中率低，考虑增大 innodb_buffer_pool_size，或检查是否有全表扫描等低效查询消耗缓存资源。
确认是否存在缓存失效或竞争问题
即使缓存配置合理，也可能因设计问题导致缓存效率低下。
- 频繁的 DML 操作（INSERT/UPDATE/DELETE）会清空相关表的查询缓存，导致缓存“雪崩”
- 使用 FLUSH QUERY CACHE; 可整理碎片（但会锁表，慎用）
- 检查慢查询日志，确认是否有相同查询反复执行却未命中缓存
- 使用 SQL_NO_CACHE 测试原始查询性能，排除缓存干扰
综合诊断建议
缓存问题往往不是孤立存在的，需结合整体负载分析。
- 开启慢查询日志：slow_query_log = ON，分析哪些查询未有效利用缓存
- 使用 EXPLAIN 检查执行计划是否走索引，避免全表扫描挤占缓存
- 监控系统 I/O，若磁盘读频繁而 buffer pool 足够大，说明数据未被有效缓存
- 对于 MySQL 8.0+ 用户：无需关注 query cache，重点优化 buffer pool 和索引设计
基本上就这些。关键是区分是缓存没起作用，还是根本不需要依赖传统查询缓存。现代应用更多依靠高效索引、连接池和外部缓存（如 Redis）来提升性能。MySQL 内部缓存调优只是其中一环。
