为什么MySQL8要无情地抛弃查询缓存？这里面到底发生了什么？

　　MySQL的查询缓存，很多朋友应该听说或者使用过，因为以前流行的一句话：现在查询这么慢，你可以开启查询缓存试试，曾经作为MySQL性能提升的一个重要特征，查询缓存为什么会被MySQL8无情的抛弃呢？今天我们就来分析分析。 什么是查询缓存
　　对于这种专业概念，我们还是引入MySQL官方文档来说吧，这样要严谨一些。
　　The query cache stores the text of a  SELECT   statement together with the corresponding result that was sent to the client. If an identical statement is received later, the server retrieves the results from the query cache rather than parsing and executing the statement again. The query cache is shared among sessions, so a result set generated by one client can be sent in response to the same query issued by another client. The query cache can be useful in an environment where you have tables that do not change very often and for which the server receives many identical queries. This is a typical situation for many Web servers that generate many dynamic pages based on database content. The query cache does not return stale data. When tables are modified, any relevant entries in the query cache are flushed.
　　从官方文档我们可以看到，查询缓存其实就是将SELECT的语句和相应的结果缓存起来并发送给客户端，如果同样的SELECT语句之后再过来，就直接返回缓存里面的查询结果，并且查询缓存是客户端共享的，一个客户端生成，其他客户端也有用。
　　但是需要说明一点，就是查询缓存不能够返回稳定的数据，如果表数据被修改，相关的条目将被清空，重新生成。 如果MySQL并发高会存在什么问题？
　　现在假设存在一种情况，就是MySQL的并发很高，针对查询缓存会出现什么问题？假设一个客户端进程读，另一个客户端进程写同一个数据表，这个时候，查询缓存是读还是不读呢？这一切的控制，让MySQL要花很大的精力去处理这种情况，比如引入锁，有变化了，就锁起来，不让读，然后变化完了，再重新生成缓存，给读端，相信并发高了，仅仅这个查询缓存都会成为MySQL性能最大问题，不仅仅没有帮我们提升性能，反而让我们的应用变得越来越慢都是有可能的。 对于查询缓存我们能够做的事情很少
　　使用过MySQL查询缓存的朋友应该知道，我们仅仅是通过MySQL提供的几个配置参数使用的，其他什么都做不了，也就是查询缓存控制，缓存命中率等，我们都无法去控制，这一切的控制都是MySQL自己去控制的，所以我们仅仅是一个使用者而已。
　　而这恰好不利于我们编程和业务发展的需要，对于我们来说，查询缓存犹如一个工具一样，我们遇到什么问题，只能够提交问题给MySQL，当然也可以修改MySQL的源代码，但是这需要的能力就非常高了。 将缓存放在客户端的好处其实很多
　　现在，我们发现Redis已经非常成熟了，在项目中多多少少都会引入Redis，比如APP登录状态的保存，手机短信验证码的保存、秒杀功能等等都可以用Redis来实现。
　　这里引入了一个问题，就是为什么我们可以用Redis来实现这么多功能呢？其中一个最重要的原因，就是，我们控制着这一切，我们可以决定什么时候失效，缓存什么数据，删除某条或者替换某条缓存条目等，当然还有很多很多控制权限，而这一切，恰好是MySQL的查询缓存无法提供的，MySQL的查询缓存相对客户端的缓存来说，真的是鸡肋。