MySQL 5.7 默认禁用query_cache，仅当query_cache_type=1且query_cache_size>1048576（1MB）时才真正启用；但因其缓存机制脆弱、易引发锁争用且命中率极低，官方已弃用，真实性能瓶颈通常在于缺失索引或低效执行计划。
MySQL 5.7 的 query_cache 已默认禁用，且仅在极少数静态场景下才可能带来收益；绝大多数业务中它不仅不生效，还会因锁争用拖慢性能。别调它，先确认你真需要它。
query_cache_type=1 且 query_cache_size > 1048576 才算真正启用
MySQL 5.7 默认是 query_cache_type = 0，哪怕你把 query_cache_size 设成 256M，缓存也不会工作。必须同时满足：
-
query_cache_type显式设为1（ON），不是2（DEMAND）或留空 -
query_cache_size必须大于1048576（即 1MB），否则 MySQL 启动时会自动置为 0 -
query_cache_size值需是 1024 的倍数，否则会被截断（比如设成 256 就是 256 字节，根本不够用） - 修改后必须重启 MySQL 进程，
SET GLOBAL不生效
哪些 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
开启后反而变慢？关键在表更新触发的全局锁
只要对某张表执行 INSERT/UPDATE/DELETE，该表所有相关缓存条目立刻失效，并抢 QUERY CACHE LOCK。这意味着：
- 订单表每秒更新 50 次 → 缓存刚写入就清空，
Qcache_hits接近 0 -
Qcache_lowmem_prunes > 0表示内存碎片严重，频繁淘汰旧缓存 -
Qcache_inserts接近Com_select→ 几乎每条 SELECT 都尝试缓存，但立刻被干掉 - 高并发读写下，锁竞争会让整体吞吐下降，比关掉还慢
MySQL 8.0+ 已彻底删除 query_cache 模块
这不是“配置没生效”，而是代码层已移除：
- 执行
SHOW VARIABLES LIKE 'query_cache%'返回空或只有have_query_cache: NO -
SHOW STATUS LIKE 'Qcache%'查不到任何以Qcache_开头的变量 - 云厂商控制台显示的“查询缓存开关”，通常是 ProxySQL 或中间件实现，和 MySQL 原生无关
- 别再查
Qcache_hits，它在 5.7 中仍存在但已无实际意义，在 8.0 中根本不存在
真实瓶颈几乎从来不在缓存——而是 EXPLAIN 里 key 列为 NULL，说明没走索引。复杂查询慢，第一反应不该是调缓存，而是看执行计划、建联合索引、避免在 WHERE 条件列上用函数。
