MySQL 5.7 的 query_cache 在绝大多数真实业务中不提升效率，反而拖慢查询；必须同时满足 query_cache_type=1 且 query_cache_size>1048576 才真正启用，但因其表级失效、全局锁争用、命中率极低等缺陷，实际常导致性能下降，官方已弃用，8.0+ 彻底移除。
MySQL 5.7 的 query_cache 在绝大多数真实业务中不提升效率，反而拖慢查询——尤其当你用的是 InnoDB、有写操作、或 SQL 带了任何动态成分。别急着配，先确认它是否真能生效。
query_cache_type=1 且 query_cache_size > 1048576 才算真正启用
MySQL 5.7 默认是 query_cache_type = 0，哪怕你把 query_cache_size 设成 256M，缓存也完全不工作。必须同时满足：
-
query_cache_type显式设为1（不是2或留空） -
query_cache_size必须大于1048576（即 1MB），否则 MySQL 启动时自动置为 0 -
query_cache_size值需是 1024 的倍数，否则会被截断（比如设成256就只剩 256 字节） - 改完必须重启
mysqld进程，SET GLOBAL不生效
验证方式：SHOW VARIABLES LIKE 'query_cache%' 应返回 query_cache_type=1 和 query_cache_size 大于 1048576 的值。
哪些 SELECT 根本不会进 query_cache，即使参数全开
就算你把参数调得再“对”，以下情况会直接跳过缓存逻辑，连尝试都不做：
- SQL 文本含任意空格/大小写/注释差异：
SELECT id FROM t;和SELECT id FROM t ;视为不同语句 - 用了非确定性函数：
NOW()、RAND()、UUID()、CURRENT_USER() - 含用户变量：
SELECT @x := 1或子查询里引用@var - 访问系统库：
information_schema、performance_schema、mysql库下的表 - 结果集超过
query_cache_limit（默认 1MB） - 语句显式加了
SQL_NO_CACHE
这意味着：只要应用里有一处 SELECT NOW()，整条查询就不可能命中缓存——你根本不用查 Qcache_hits。
开启后反而变慢？关键在表更新触发的全局锁
只要对某张表执行 INSERT/UPDATE/DELETE，该表所有相关缓存条目立刻失效，并抢 QUERY CACHE LOCK。后果很直接：
- 订单表每秒更新 50 次 → 缓存刚写入就清空，
Qcache_hits接近 0 -
Qcache_lowmem_prunes > 0表示内存碎片严重，频繁淘汰旧缓存 -
Qcache_inserts接近Com_select→ 几乎每条SELECT都尝试缓存，但立刻被干掉 - 高并发读写下，锁竞争会让整体吞吐下降，比关掉还慢
InnoDB 表越活跃，这个现象越明显；只读从库也会因主库同步触发的隐式刷新而持续失效。
MySQL 8.0+ 已彻底删除 query_cache 模块
这不是“配置没生效”，而是代码层已移除：
- 执行
SHOW VARIABLES LIKE 'query_cache%'返回空，或只有have_query_cache: NO -
SHOW STATUS LIKE 'Qcache%'查不到任何以Qcache_开头的变量 - 云厂商控制台显示的“查询缓存开关”，通常是 ProxySQL 或中间件实现，和 MySQL 原生无关
如果你正在用 MySQL 8.0+，别再找 query_cache_type，它不存在。真实瓶颈几乎从来不在这里——而是 EXPLAIN 里 key 列为 NULL，或是 innodb_buffer_pool_size 没调够。
