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 去测试缓存效果。
