MySQL 8.0起查询缓存已被彻底移除，query_cache_type和query_cache_size配置无效，启动会报错；其废弃主因是命中率低、锁竞争高、失效逻辑复杂，反而降低高并发性能。
MySQL 8.0 以后查询缓存已被移除，query_cache_type 不再生效
直接说结论：如果你用的是 MySQL 8.0 或更新版本（包括所有 Percona Server 8.x、MariaDB 10.6+），query_cache_size 和 query_cache_type 这两个配置项已彻底删除，配置文件里写了也无效，启动时会报 Unknown variable 'query_cache_type' 警告，甚至无法启动。
这是官方明确废弃的功能——因为查询缓存存在严重缺陷：缓存命中率低、锁竞争高、失效逻辑复杂（一张表被 UPDATE 就让全库相关缓存失效），反而在高并发场景拖慢性能。
所以别再找“如何开启 MySQL 查询缓存”的教程了，除非你还在用 MySQL 5.7 或更老版本（且确认业务场景确实适合）。
MySQL 5.7 中启用查询缓存的实操要点
仅适用于 MySQL 5.7（含 5.7.20 之前版本），且必须满足以下条件才可能有收益：
-
query_cache_type = 1（ON）或= 2（DEMAND，需 SQL 显式加SQL_CACHE） -
query_cache_size > 1048576（至少 1MB，否则自动禁用） - 查询必须是确定性 SELECT（不能含
NOW()、USER()、子查询含临时表等） - 涉及的表未被其他连接执行过
INSERT/UPDATE/DELETE
常见错误配置：
- 只设
query_cache_size = 1048576，但没开query_cache_type→ 缓存不工作 - 设了
query_cache_size = 0→ 启动后SHOW VARIABLES LIKE 'query_cache%'全为 OFF/0 - 用
SELECT SQL_NO_CACHE ...测试时误以为缓存失效是 bug → 实属正常行为
替代查询缓存的真实性能调优方向
现代 MySQL 性能瓶颈极少出在“重复查相同 SQL”上，更多卡在 I/O、锁、执行计划、连接数。优先检查这些：
- 确保
innodb_buffer_pool_size设为物理内存的 50%–75%（不是默认的 128MB） - 关闭
innodb_flush_log_at_trx_commit = 2（若可接受秒级数据丢失） - 用
EXPLAIN FORMAT=JSON查看慢查询是否走了索引；避免SELECT *和隐式类型转换 - 监控
Threads_connected和Aborted_connects，防止连接泄漏或认证失败风暴 - 用
performance_schema开启events_statements_history_long抓取 Top SQL，而非依赖缓存命中率
如果真有高频固定结果集（比如配置表、地区字典），应用层用 Redis / local cache 更可控、更高效。
验证查询缓存是否工作的命令和陷阱
在 MySQL 5.7 环境下，用以下方式验证（注意：必须用新连接、无其他写操作干扰）：
SELECT SQL_NO_CACHE COUNT(*) FROM orders; SELECT SQL_CACHE COUNT(*) FROM orders; SHOW STATUS LIKE 'Qcache%';
关键指标看：
-
Qcache_hits：缓存命中次数（增长说明起效） -
Qcache_inserts：新缓存条目数（太高说明重复查询少或缓存碎片多） -
Qcache_lowmem_prunes：因内存不足被挤掉的缓存数（持续增长说明query_cache_size太小或缓存太碎）
容易忽略的一点：MySQL 查询缓存对大小写敏感、空格敏感、注释敏感——SELECT * FROM t 和 SELECT * FROM t; 是两条不同缓存。别用 ORM 自动生成带随机注释的 SQL 去测试缓存效果。
