Mysql 的 Query Cache为什么被废弃

MySQL 的 Query Cache（查询缓存） 在早期版本中被设计用于缓存查询结果，以加速重复查询的执行。然而，从 MySQL 5.7 开始默认禁用，并在 MySQL 8.0 中彻底移除。其废弃的主要原因如下：

**1. 锁竞争与性能瓶颈

• 全局锁机制：Query Cache 使用全局锁（LOCK_query_cache）管理缓存操作，高并发场景下，频繁的缓存查询、更新和失效操作会导致严重的锁竞争。

• 读/写冲突：即使查询命中缓存，仍需获取锁来验证缓存有效性，反而可能降低并发性能。

**2. 缓存失效成本高

• 表级失效：任何对表的修改（如INSERT、UPDATE、DELETE）都会导致该表关联的所有缓存条目失效。对于写频繁的场景，缓存命中率极低，维护成本远高于收益。

• “缓存污染”：少量高频修改的表会导致大量缓存被频繁清除，缓存难以稳定存在。

**3. 内存管理效率低

• 固定内存分配：Query Cache 需要预分配固定大小的内存（通过query_cache_size配置），无法动态调整，容易导致内存浪费或不足。

• 哈希表维护开销：缓存条目通过哈希表管理，内存碎片化和哈希碰撞会降低查询效率。

**4. 适用场景有限

• 只缓存完全相同的查询：SQL 必须严格一致（包括空格、大小写等），实际应用中命中率较低。

• 静态数据场景少：现代应用多为读写混合型业务，纯读场景较少，Query Cache 难以发挥作用。

**5. 存在更优的替代方案

• 应用层缓存：如 Redis、Memcached 等，提供更灵活、可控的缓存策略，支持分布式和高可用。

• InnoDB Buffer Pool：MySQL 的 InnoDB 引擎通过缓冲池（Buffer Pool）缓存热数据页，更贴近存储引擎层，效率更高。

• 优化器改进：MySQL 优化器的进步（如索引条件下推、覆盖索引）减少了全表扫描的需求，降低了对结果集缓存的依赖。

**6. 设计缺陷与维护成本

• 复杂性高：Query Cache 的实现与事务、隔离级别等机制耦合，导致代码维护困难。

• 功能局限性：不支持部分缓存或动态缓存策略，无法适应复杂查询需求。

总结

MySQL 废弃 Query Cache 的核心原因在于其锁竞争严重、维护成本高、适用场景狭窄，与现代高并发、动态数据场景的需求不匹配。实际开发中，更推荐通过以下方式优化查询性能：

• 合理设计索引（如覆盖索引）。

• 优化 SQL 语句，避免全表扫描。

• 使用应用层缓存（如 Redis）或 InnoDB Buffer Pool。

• 利用读写分离、分库分表等架构优化。