最可靠方法是执行查询前后对比Qcache_hits值是否增加1，仅适用于单线程调试；命中需同时满足query_cache_type启用、SQL完全合规（大小写/空格敏感）、所涉表无任何DML/DDL变更。
直接查 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;vsselect id from users;（大小写不同） -
SELECT id FROM users;vsSELECT id FROM users;（多余空格） -
SELECT id FROM test.users;vsSELECT id FROM users;（显式指定数据库名） -
SELECT * FROM users WHERE id = 1;vsSELECT * FROM users WHERE id = 2;（常量不同 → 哈希值不同）
这意味着 ORM 自动生成的 SQL（比如带换行、缩进、参数拼接）几乎不可能复用缓存；预编译 PREPARE + EXECUTE 也不起作用，因为每次绑定参数后生成的完整 SQL 字符串仍不同。
命中前必须过三关：配置开、SQL合规、表没被改
即使你看到 Qcache_hits 在涨，也不能断定“这条 SQL 被缓存了”——它可能是其他完全相同的查询带来的。真正决定某次查询能否命中，取决于三个硬性条件同时满足：
-
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 这类真实影响性能的指标。
