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。
-
利用读写分离、分库分表等架构优化。
