如何判断MySQL查询是否命中了Query Cache缓存-mysql教程-PHP中文网

最可靠方法是执行查询前后对比qcache_hits值是否增加1，仅适用于单线程调试；命中需同时满足query_cache_type启用、sql完全合规（大小写/空格敏感）、所涉表无任何dml/ddl变更。

如何判断mysql查询是否命中了query cache缓存

直接查 `Qcache_hits` 状态变量最可靠

MySQL 不会在查询返回时告诉你“这次命中缓存了”，唯一能确认是否命中的办法，是观察全局状态计数器的变化。执行一次查询前后，对比 Qcache_hits 是否增加：

先执行 SHOW STATUS LIKE 'Qcache_hits'; 记下当前值
再执行你的目标 SELECT 语句
立刻再执行一次 SHOW STATUS LIKE 'Qcache_hits';
如果数值增加了 1，说明这次查询命中了 Query Cache

注意：这个方法只适用于单线程、低并发调试场景。高并发下多个查询可能同时触发命中，Qcache_hits 增量无法精确归属到某一条语句。

`SELECT` 必须完全一致才能命中，空格和大小写都算不同查询

Query Cache 的匹配是**逐字节哈希比对**，不是语义等价判断。下面这些写法，哪怕逻辑相同，也全算不同查询，彼此不共享缓存：

SELECT id FROM users; vs select id from users;（大小写不同）
SELECT id FROM users; vs SELECT id FROM users;（多余空格）
SELECT id FROM test.users; vs SELECT id FROM users;（显式指定数据库名）
SELECT * FROM users WHERE id = 1; vs SELECT * FROM users WHERE id = 2;（常量不同 → 哈希值不同）

这意味着 ORM 自动生成的 SQL（比如带换行、缩进、参数拼接）几乎不可能复用缓存；预编译 PREPARE + EXECUTE 也不起作用，因为每次绑定参数后生成的完整 SQL 字符串仍不同。

命中前必须过三关：配置开、SQL合规、表没被改

即使你看到 Qcache_hits 在涨，也不能断定“这条 SQL 被缓存了”——它可能是其他完全相同的查询带来的。真正决定某次查询能否命中，取决于三个硬性条件同时满足：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

query_cache_type 必须为 1 或 2，且 query_cache_size > 0
该 SELECT 不能含任何禁止缓存的成分：NOW()、RAND()、SQL_NO_CACHE、LOCK IN SHARE MODE、用户变量、系统库表、警告（Warnings）等
查询涉及的所有表，在上次缓存写入后**未发生任何 DML/DDL**（哪怕只改了一行，整张表关联的所有缓存条目都会被清空）

所以常见误判：看到 Qcache_inserts 增加了，就以为缓存成功 —— 其实可能刚插入就被 UPDATE users SET name='x' WHERE id=1 清掉了，下次再查照样 miss。

`FLUSH QUERY CACHE` 不清数据，但会暴露碎片问题

FLUSH QUERY CACHE 这个命令名字有误导性：它**不会删除任何缓存条目**，只是把内存块重新整理，合并空闲区域。但它会重置 Qcache_free_blocks 和 Qcache_total_blocks，让碎片情况变得可见。

如果你发现 Qcache_lowmem_prunes 持续上升，而 Qcache_free_memory 却不低，大概率是碎片太多导致新查询申请不到连续内存块。这时 FLUSH QUERY CACHE 可临时缓解，但治标不治本 —— 根子往往在 query_cache_min_res_unit 设得过大，或缓存本身已不适合当前业务模式。

真要验证某条 SQL 是否稳定命中，别依赖一时的状态波动；得关掉所有写流量，用固定 SQL 循环跑，再盯住 Qcache_hits 和 Qcache_inserts 的比例。不过现在 MySQL 8.0 已移除 Query Cache，生产环境更该关心的是 innodb_buffer_pool_reads 和 innodb_buffer_pool_read_requests 这类真实影响性能的指标。