MySQL 查询缓存（Query Cache）是 MySQL 5.7 及更早版本中存在、但在 8.0 版本中已被彻底移除的一项功能。它不是缓存数据页或索引，而是直接缓存 SELECT 查询的完整结果集，命中后跳过解析、优化、执行全过程，从内存返回结果。
它怎么判断是否能用？
缓存命中依赖完全一致的 SQL 字符串：大小写、空格、注释、结尾分号，哪怕多一个空格都算不同语句。例如：
SELECT id FROM user;-
SELECT id FROM user ;（末尾空格）→ 不命中 -
SELECT ID FROM user;（大写 ID）→ 不命中 -
/* 注释 */ SELECT id FROM user;→ 不命中
同时要求数据库名、字符集、协议版本等上下文完全相同；含 NOW()、RAND()、CURRENT_DATE 等非确定性函数的查询，不会被缓存。
它为什么会被淘汰？
核心问题在于缓存失效太粗暴、太频繁：
- 只要表发生一次
INSERT/UPDATE/DELETE/ALTER TABLE，该表所有相关缓存立即清空 - 高并发写场景下，缓存刚写入就失效，命中率趋近于零
- 全局哈希锁竞争严重，多个线程争抢缓存结构时反而拖慢读性能
- 不校验用户权限变更，存在越权访问风险
- 缓存空间易碎片化，管理开销大
现在该用什么替代？
真实业务中，更合理、更可控的缓存已下沉到其他层级：
-
InnoDB 缓冲池（
innodb_buffer_pool_size）：缓存的是数据页和索引页，对所有读请求透明生效，无 SQL 字符串敏感问题，是当前 MySQL 最核心的缓存机制 - 应用层缓存（如 Redis）：由业务控制缓存键、过期策略与更新逻辑，适合配置表、地区列表、报表结果等高频低更新场景
- 代理层缓存（如 ProxySQL）：可按规则开启结果缓存，粒度更细，不与表更新强绑定
- 客户端/连接层预加载：静态配置类数据可在应用启动时加载进本地内存，避免反复查库
如何确认你有没有这个功能？
在 MySQL 8.0+ 中执行：
SHOW VARIABLES LIKE 'query_cache%';
若只返回 have_query_cache: NO 或无任何结果，说明该功能已不存在，不是“关了”，是代码里删干净了。
再执行：SHOW STATUS LIKE 'Qcache%';
若没有任何以 Qcache_ 开头的状态变量，也印证这一点。
注意别混淆：innodb_buffer_pool_size 是 InnoDB 缓冲池，和查询缓存无关；云厂商控制台显示的“查询缓存开关”，往往是其代理层实现，并非 MySQL 原生机制。
