17370845950

MySQL 8.0 已彻底移除 Query Cache，因其缓存粒度粗、全局锁瓶颈、命中率低且不支持现代 SQL 特性；推荐采用应用层缓存、Buffer Pool 优化及读写分离等分层策略替代。

MySQL 5.7 及更早版本中的 Query Cache（查询缓存）已被官方弃用，并在 MySQL 8.0 中彻底移除。它曾试图通过缓存 SELECT 查询结果来加速重复读操作，但实际使用中常因失效频繁、锁竞争严重、命中率低等问题反而拖慢系统性能。

Query Cache 的工作原理与核心缺陷

Query Cache 在服务端对完整 SQL 文本做哈希计算，匹配后直接返回缓存的结果集。它要求查询语句完全一致（包括空格、大小写、注释），且涉及的表只要发生任何 DML（INSERT/UPDATE/DELETE）或 DDL 操作，该表关联的所有缓存条目就会被清空。

• 缓存粒度粗：一张表更新，所有查这张表的语句缓存全失效
• 全局锁瓶颈：每个查询/更新都需获取 query cache lock，高并发下成为热点锁
• 内存管理低效：固定内存块分配，易产生碎片，无法动态伸缩
• 不支持大多数现代用法：如 Prepared Statement、包含函数（NOW()、RAND()）、用户变量等均被自动排除

为什么主流应用早已绕过 Query Cache

真实业务场景中，查询参数多变、数据更新频繁、SQL 生成方式多样（ORM、拼接、分页偏移等），导致 Query Cache 命中率普遍低于 10%。运维人员常发现开启后 QPS 不升反降，TPS 波动加剧，最终选择显式关闭（query_cache_type=0）。

• 应用层缓存（Redis、Memcached）更灵活：可按业务语义缓存，支持 TTL、分级、穿透保护
• 连接层代理（如 ProxySQL、MaxScale）可实现语法无关的简单结果缓存
• 数据库内核优化转向更底层：Buffer Pool 加大、索引优化、执行计划复用（PS Cache）、只读副本分流

替代方案与现代实践建议

当前高性能 OLTP 场景下，不应再依赖服务端查询缓存机制，而应构建分层缓存策略：

• 热键识别 + 应用缓存：用 Redis 缓存高频、低更新频率的维度数据（如城市列表、配置项）
• 结果集缓存粒度下沉：缓存“用户ID → 订单列表”而非“SELECT * FROM orders WHERE uid=?”
• 利用 MySQL 的 InnoDB Buffer Pool：合理设置 innodb_buffer_pool_size（通常为物理内存 50%–75%），让热数据常驻内存
• 读写分离 + 只读实例缓存：将查询压力导向只读副本，其本地 Buffer Pool 同样可复用热页

小结：从 Query Cache 到缓存意识的升级

Query Cache 的消亡不是缓存价值的否定，而是对“通用、透明、服务端强制缓存”思路的反思。真正有效的缓存必须理解业务语义、可控失效、可监控、可降级。与其纠结一条 SQL 是否被缓存，不如花时间厘清数据访问模式、划分冷热层级、设计合理的缓存键和过期策略。