MySQL 8.0 已彻底移除查询缓存模块，query_cache_type等变量不存在；5.7及以前需满足type=1、size>1MB等条件才生效；推荐用Redis、预计算表、覆盖索引等替代方案。
MySQL 查询缓存已被移除，query_cache_type 在 8.0 中无效
MySQL 8.0 起彻底删除了查询缓存（Query Cache）模块，query_cache_type、query_cache_size 等所有相关系统变量已不存在。如果你在 8.0+ 实例中执行 SHOW VARIABLES LIKE 'query_cache%'，结果为空；设为 1 会报错 Unknown system variable 'query_cache_type'。这不是配置没生效，而是代码层已移除。
5.7 及更早版本开启查询缓存的必要条件
即使在支持版本中，查询缓存也默认关闭（query_cache_type = 0），且需同时满足多个条件才真正生效：
-
query_cache_type = 1（ON）且query_cache_size > 1048576（即大于 1MB，否则自动禁用） - SQL 必须是确定性 SELECT：不能含
NOW()、CURRENT_DATE()、用户变量、SELECT ... FOR UPDATE、子查询中含非确定函数等 - 涉及的表未被任何线程执行过
INSERT/UPDATE/DELETE，否则该表对应的所有缓存条目立即失效 - 查询结果集大小不能超过
query_cache_limit（默认 1MB），超限则不缓存
典型失效场景：SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL 1 DAY 因含 NOW()，每次都不走缓存。
替代方案：应用层缓存比 MySQL 查询缓存更可控
MySQL 原生查询缓存因粒度粗（整表变更即清空）、锁竞争高（query_cache_mutex）、命中率低等问题，官方明确建议弃用。实际优化应转向：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用
Redis或Memcached缓存高频只读结果，键可基于 SQL MD5 或业务语义生成，如user_orders_12345 - 对聚合类慢查询，预计算写入汇总表（如
daily_sales_summary），避免实时扫描大表 - 利用客户端连接池的 prepared statement 缓存（如 MySQL Connector/J 的
cachePrepStmts=true），减少解析开销 - 确认是否真需要“查询级”缓存——多数场景下，合理设计索引 + 减少
SELECT *+ 使用覆盖索引，比依赖查询缓存更有效
SELECT id, name, status FROM users WHERE status = 'active' AND city = 'shenzhen';
若该查询频繁，建联合索引 (status, city, id, name)，让其走覆盖索引，比指望查询缓存更稳定可靠。
检查是否误以为还在用查询缓存
很多运维或开发看到 Qcache_hits 非零就认为缓存生效，但要注意：
- 5.7 中
SHOW STATUS LIKE 'Qcache%'仍返回统计值，但只要query_cache_size = 0，所有命中均为 0 —— 检查前先确认变量值 - Percona Server 或 MariaDB 可能保留兼容接口，但行为与原生 MySQL 不同，需查对应版本文档
- 监控工具（如 Zabbix 模板）若硬编码采集
Qcache_hits，在 8.0 上会采集失败或返回 NULL，需及时更新指标逻辑
真正影响性能的，往往是没走索引的全表扫描，而不是“查询缓存没开”。别在已消失的功能上浪费调优时间。
