MySQL 的查询缓存（Query Cache）在 MySQL 8.0 中被废弃并最终移除，主要原因如下：
1. 查询缓存的局限性
- 缓存无效化频繁: 查询缓存会将完整的查询结果存储起来，以便在相同查询被重复执行时直接返回结果。然而，任何对涉及的表进行的写操作（如
INSERT、UPDATE、DELETE）都会使缓存中的相关查询结果失效。对于高写入频率的数据库，查询缓存频繁无效化，导致缓存命中率低，无法带来显著的性能提升，甚至可能对整体性能产生负面影响。 - 局部无效化难以实现: 查询缓存是基于整个查询的结果集进行缓存的，因此即使是对表中一行的更新，也会导致缓存中所有涉及该表的查询结果无效化。由于缓存粒度较粗，在复杂的数据库应用中，这种行为导致缓存的实际效用大幅下降。
2. 性能开销
- 锁争用问题: 查询缓存会引发锁争用问题，特别是在高并发环境中。当查询缓存被启用时，服务器需要管理多个线程对缓存的访问、插入和无效化操作，这会增加锁争用的机会，从而降低整体系统性能。
- 维护开销: 对于查询缓存的管理和维护，MySQL 服务器需要额外的资源和计算开销。这些开销在某些情况下可能会超过缓存所带来的性能收益，尤其是在缓存命中率不高的情况下。
3. 现代硬件和软件架构的影响
- 内存和处理能力的提高: 现代硬件架构拥有更高的内存容量和处理能力，使得查询缓存的作用变得不那么显著。通过适当的索引和优化查询，查询性能已经能够得到较好的保障，减少了对查询缓存的依赖。
- 分布式系统的普及: 随着分布式数据库系统和水平扩展架构的普及，查询缓存在多节点环境中的一致性维护变得更加复杂和低效。许多现代数据库和应用程序更倾向于在应用层实现缓存（如使用 Redis 或 Memcached）来获得更灵活和高效的缓存解决方案。
4. 改进的优化器和缓存策略
- 查询优化器的改进: MySQL 以及其他数据库系统在查询优化方面不断改进，使得查询执行效率大幅提高，减少了对查询缓存的需求。
- 其他缓存机制的替代: 开发者越来越多地使用应用层缓存（如 Redis、Memcached）以及数据库内部的其他缓存机制（如 InnoDB Buffer Pool），这些方法提供了更细粒度、更高效的缓存策略，能够更好地适应现代应用的需求。
总结
由于查询缓存的局限性、性能开销，以及现代硬件和软件架构的发展，MySQL 团队决定在 MySQL 8.0 中废弃并移除查询缓存。开发者现在更倾向于通过应用层缓存、适当的索引和查询优化，以及使用内存数据库等手段来提升查询性能，而不再依赖数据库层面的查询缓存。
