先说概念：

MySQL 的查询缓存（Query Cache）是一种在服务层级别缓存查询结果的机制。当一个查询被执行时，MySQL 会将查询语句及其对应的结果存储在内存中的查询缓存中。如果后续有相同的查询请求到达，MySQL 可以直接从缓存中返回结果，而无需再执行实际的查询操作，从而提供快速的查询响应。

根据其特性，查询缓存的使用可以带来以下几点好处：
1、加速查询响应：如果一个查询在缓存中已经存在，并且查询缓存是启用的，MySQL 可以立即返回之前查询的结果，而无需再次访问底层数据表，从而显著提高查询性能和响应速度。
2、减少CPU和IO开销：通过避免重复执行相同的查询，查询缓存可以减少数据库服务器的 CPU 和 IO 负载，允许处理更多的并发查询请求。

弊端

但是查询缓存也存在一些限制和注意事项：
1、缓存失效成本高：当任何一个表发生增删改操作时，与该表相关的所有缓存都被标记为无效，并在下次查询时被清除。对于频繁进行写操作或更新的表，缓存命中率可能很低，甚至会成为一种性能负担。
2、不适用于大多数动态或复杂查询：查询缓存只适用于完全相同的查询，如果查询中包含任何变量、函数、子查询、临时表或用户定义函数，则无法从缓存中获益。
3、占用内存：查询缓存需要占用一部分内存来存储查询语句和结果，过大的查询缓存可能导致内存压力，并且可能会影响其他重要的数据结构，如连接池或数据库缓冲池。

从诞生到淘汰

其实MySQL在很早期的版本中就引入的查询缓存，甚至可以追溯到2000年代。
那时候互联网还没有很成熟，数据量也远远没有现在炸裂，甚至绝大多数用MySQL的业务都不需要挂一层Redis，所以MySQL自身搞了个查询缓存，目的应该是想如果一些数据被频繁查询则直接走缓存。
但是自 MySQL 5.7.20 版本开始，MySQL 默认将查询缓存功能禁用。在使用 MySQL 8.0 或更高版本时，查询缓存已经被完全移除。
为什么查询缓存在MySQL中就走到头了呢，原因有几个：
1、MySQL终归是适合做逻辑、事务处理的数据库。当互联网逐渐成熟，数据量越来越爆炸时，自然就诞生出了Redis这种KV适合做缓存场景的数据库，相较使用MySQL专门分出一块内存来做查询缓存，明显Redis更加高效和稳定。
2、查询缓存本身。在MySQL中查询缓存的实现方式是必须完全相同的SQL才会触发使用到查询缓存，这点就使得MySQL中的查询缓存功能非常鸡肋了，再不济select a from t where id=xxx 每个用户查的都不是同一个id嘛。

所以综合来看MySQL中的查询缓存劣势远远大于优势，被时代淘汰也理所当然了。