MySQL 5.6/5.7 中 query_cache_type=0 仅禁用自动缓存，若 query_cache_size>0，SQL_CACHE 提示仍可触发缓存；真正禁用需同时设 query_cache_size=0 以释放内存并彻底忽略缓存逻辑。
MySQL 5.7 中 query_cache_type 为 0 却仍不生效？
不是设成 0 就代表“关闭”，它只是禁用自动缓存，SQL_CACHE 提示仍可能触发缓存。真正停用需同时设 query_cache_size = 0 —— 否则内存池还在，只是不自动用。
常见错误现象：SHOW STATUS LIKE 'Qcache%' 仍显示非零值，Qcache_hits 持续增长，但业务查询没走缓存预期路径。
-
query_cache_type = 0：跳过自动缓存逻辑，但显式写SELECT SQL_CACHE ...仍会尝试缓存（若size > 0） -
query_cache_size = 0：彻底释放缓存内存，所有缓存操作直接忽略，Qcache_queries_in_cache必为 0 - MyISAM 表更新会清空整个缓存；InnoDB 表虽稍好，但只要涉及同一张表的写操作，相关缓存条目全失效
为什么 MySQL 8.0 直接删了 query cache？
不是功能做不好，是它在高并发、多核、InnoDB 主导的场景下成了性能拖累。缓存锁争用比预想严重得多，尤其当多个线程频繁读同一张表时，query cache mutex 成为瓶颈。
典型表现：SHOW PROFILE 显示大量时间卡在 Waiting for query cache lock，CPU 利用率不高但 QPS 上不去。
- 缓存失效粒度太粗：一条
UPDATE可能清掉几百条 SELECT 缓存 - 无法区分不同事务隔离级别下的结果一致性，容易返回脏数据（尤其 READ-COMMITTED 下）
- InnoDB 的 buffer pool + 自适应哈希索引 + 更快的解析器，让多数简单查询本身已足够快，缓存收益被摊薄
MySQL 8.0+ 真实可用的替代方案有哪些？
别指望一个开关就能复刻旧 query cache，得按场景拆解：热数据、固定维度聚合、接口级缓存，各自有更稳的解法。
- 应用层加 Redis：对确定性高、更新不频繁的查询（如配置表、城市列表），查完立刻
SETEX key 3600 result，比数据库缓存更可控 - 利用
innodb_buffer_pool_size：把常用表/索引“喂饱”，让物理读变逻辑读，效果远超 query cache，且无失效风暴 - 物化视图思路（用定时任务+临时表）：对慢聚合查询（如日活统计），每小时跑一次
CREATE TABLE daily_stats AS SELECT ...，应用查这张表 - 客户端缓存（HTTP Cache-Control）：如果是 API 场景，对只读接口加
Cache-Control: public, max-age=300，把压力卸到 CDN 或浏览器
升级前必须检查的三个地方
很多团队升级 8.0 后才发现老代码里埋着 SQL_CACHE，虽然 MySQL 忽略它，但语法错误不会报，只是默默变慢——因为优化器少了这个 hint，执行计划可能退化。
- 搜全部 SQL 文件里的
SQL_CACHE和SQL_NO_CACHE，删掉或替换成注释 - 检查监控项是否还依赖
Qcache_hits/Qcache_inserts，这些状态变量在 8.0 已不存在，再查会返回空 - 确认备份脚本、慢日志分析工具是否硬编码了 query cache 相关字段，否则解析失败或漏报
最麻烦的不是技术替换，是那些没写文档、没人维护、但每天都在跑的定时 SQL 脚本——它们最容易藏着 query cache 的幽灵用法。
