MySQL 5.7.33起完全废弃查询缓存，8.0.0正式删除，query_cache_type等参数无效；盲目调大query_cache_size反致性能下降；推荐用Redis、内存缓存、预生成报表及调优innodb_buffer_pool_size替代。
MySQL 5.7 及以后版本已彻底移除查询缓存（query_cache_type、query_cache_size 等参数无效），强行配置不会生效。如果你正在用 MySQL 8.0+ 或 MariaDB 10.6+，这部分配置直接跳过——不是你没配对，是它已经没了。
为什么 query_cache_type 设成 1 却没效果
常见现象：在 my.cnf 里写了
[mysqld] query_cache_type = 1 query_cache_size = 268435456
重启后执行 SHOW VARIABLES LIKE 'query_cache%'; 发现值全为 0，或者 SHOW STATUS LIKE 'Qcache%'; 没有统计项。
- MySQL 5.7.20 开始默认禁用查询缓存，5.7.33 起完全废弃；
- MySQL 8.0.0 正式删除所有查询缓存相关代码，
query_cache_type变成只读变量，设了也白设； - 即使降级到 MySQL 5.6，InnoDB 表频繁更新也会让缓存频繁失效，实际命中率常低于 5%。
query_cache_size 不是越大越好
哪怕你还在用 MySQL 5.6，盲目调大 query_cache_size 可能拖慢整体性能：
- 查询缓存使用全局互斥锁，高并发下多个线程争抢
Qcache_lock，反而卡住查询； - 缓存块管理开销随大小增长，
query_cache_size > 256MB时碎片化严重，有效利用率暴跌； -
query_cache_limit默认仅 1MB，大于该值的查询结果根本不会进缓存，调大query_cache_size前必须同步调高它。
真正能提高“缓存命中”的替代方案
与其纠结已淘汰的查询缓存，不如把资源投向更可控、更高效的路径：
- 应用层用
Redis或Memcached缓存完整查询结果，自己控制 key 生效逻辑和失效时机； - 对静态/低频变更数据（如配置表、省市区字典），在应用启动时加载进内存，查的时候根本不走 DB；
- 用
SELECT ... INTO OUTFILE+ 定时预生成静态报表页，绕过实时查询； - InnoDB 层面重点调优
innodb_buffer_pool_size（建议设为物理内存的 70–80%），让热数据常驻内存，比 SQL 级缓存更底层、更稳定。
最后提醒一句：查询缓存的“完全匹配”规则（区分空格、大小写、注释）在真实业务中极难维持，连 ORM 拼出的 SQL 都可能因参数顺序或换行不同而 miss。这点最容易被忽略，但恰恰是它在生产环境失效的核心原因。
