MySQL 8.0 移除查询缓存因其严格命中条件、全局锁竞争、频繁失效和低内存效率，在高并发场景下反成性能瓶颈，且维护成本高于收益；现推荐使用 Redis/Memcached、InnoDB 缓冲池和 ProxySQL 等更高效、可控的外部缓存方案。
MySQL 查询缓存（Query Cache）在早期版本中被用来提升读操作性能，但自 MySQL 8.0 起已被彻底移除。这背后并非偶然，而是基于实际使用中的诸多限制和并发问题所做出的决策。
查询缓存的工作机制
查询缓存的核心思想是：将 SELECT 语句的文本作为键，查询结果作为值进行存储。当接收到相同的 SQL 时，MySQL 直接从缓存中返回结果，跳过了解析、优化和执行过程。
这个机制听起来高效，但在真实场景中却容易成为性能瓶颈。它的命中条件非常严格：
- SQL 语句必须完全一致（包括空格、大小写）
- 涉及的表没有发生任何数据变更
- 同一客户端连接的上下文环境一致（如字符集、SQL 模式等）
为什么查询缓存会被弃用
尽管初衷良好，查询缓存在高并发或频繁写入的场景下表现不佳，主要原因如下：
- 全局锁竞争严重：所有查询和更新操作都需要访问同一个查询缓存结构，导致严重的锁争用，尤其在多核服务器上反而降低整体吞吐量
- 缓存失效过于频繁：只要表有任意 INSERT、UPDATE、DELETE 操作，该表相关的所有查询缓存都会被清空，写操作越多，缓存命中率越低
- 内存管理效率低：缓存碎片化严重，且无法有效控制缓存淘汰策略，长时间运行后性能下降明显
- 收益与维护成本不成正比：在大多数现代应用中，SQL 多样性高，重复查询比例低，缓存利用率不高
替代方案更高效
MySQL 移除查询缓存后，推荐使用更灵活、可控的外部缓存机制：
- 使用 Redis 或 Memcached 在应用层缓存热点查询结果，可以精确控制缓存粒度和生命周期
- 利用 InnoDB 的缓冲池（Buffer Pool）高效缓存数据页，这是真正影响性能的关键内存区域
- 通过数据库代理（如 ProxySQL）实现查询结果缓存，具备更好的并发处理能力
总结
查询缓存的废弃不是功能倒退，而是架构演进的必然选择。它在简单场景下可能有效，但无法适应现代高并发、分布式系统的复杂需求。取而代之的是更精细、可扩展的缓存策略，把缓存控制权交给更适合的应用层或中间件。
基本上就这些——老机制退出历史舞台，是为了给更高效的解决方案腾出空间。
