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

　　MySQL的查询缓存，很多朋友应该听说或者使用过，因为以前流行的一句话：现在查询这么慢，你可以开启查询缓存试试，曾经作为MySQL性能提升的一个重要特征，查询缓存为什么会被MySQL8无情的抛弃呢？今天我们就来分析分析。什么是查询缓存
　　对于这种专业概念，我们还是引入MySQL官方文档来说吧，这样要严谨一些。
　　ThequerycachestoresthetextofaSELECTstatementtogetherwiththecorrespondingresultthatwassenttotheclient。Ifanidenticalstatementisreceivedlater，theserverretrievestheresultsfromthequerycacheratherthanparsingandexecutingthestatementagain。Thequerycacheissharedamongsessions，soaresultsetgeneratedbyoneclientcanbesentinresponsetothesamequeryissuedbyanotherclient。Thequerycachecanbeusefulinanenvironmentwhereyouhavetablesthatdonotchangeveryoftenandforwhichtheserverreceivesmanyidenticalqueries。ThisisatypicalsituationformanyWebserversthatgeneratemanydynamicpagesbasedondatabasecontent。Thequerycachedoesnotreturnstaledata。Whentablesaremodified，anyrelevantentriesinthequerycacheareflushed。
　　从官方文档我们可以看到，查询缓存其实就是将SELECT的语句和相应的结果缓存起来并发送给客户端，如果同样的SELECT语句之后再过来，就直接返回缓存里面的查询结果，并且查询缓存是客户端共享的，一个客户端生成，其他客户端也有用。
　　但是需要说明一点，就是查询缓存不能够返回稳定的数据，如果表数据被修改，相关的条目将被清空，重新生成。如果MySQL并发高会存在什么问题？
　　现在假设存在一种情况，就是MySQL的并发很高，针对查询缓存会出现什么问题？假设一个客户端进程读，另一个客户端进程写同一个数据表，这个时候，查询缓存是读还是不读呢？这一切的控制，让MySQL要花很大的精力去处理这种情况，比如引入锁，有变化了，就锁起来，不让读，然后变化完了，再重新生成缓存，给读端，相信并发高了，仅仅这个查询缓存都会成为MySQL性能最大问题，不仅仅没有帮我们提升性能，反而让我们的应用变得越来越慢都是有可能的。对于查询缓存我们能够做的事情很少
　　使用过MySQL查询缓存的朋友应该知道，我们仅仅是通过MySQL提供的几个配置参数使用的，其他什么都做不了，也就是查询缓存控制，缓存命中率等，我们都无法去控制，这一切的控制都是MySQL自己去控制的，所以我们仅仅是一个使用者而已。
　　而这恰好不利于我们编程和业务发展的需要，对于我们来说，查询缓存犹如一个工具一样，我们遇到什么问题，只能够提交问题给MySQL，当然也可以修改MySQL的源代码，但是这需要的能力就非常高了。将缓存放在客户端的好处其实很多
　　现在，我们发现Redis已经非常成熟了，在项目中多多少少都会引入Redis，比如APP登录状态的保存，手机短信验证码的保存、秒杀功能等等都可以用Redis来实现。
　　这里引入了一个问题，就是为什么我们可以用Redis来实现这么多功能呢？其中一个最重要的原因，就是，我们控制着这一切，我们可以决定什么时候失效，缓存什么数据，删除某条或者替换某条缓存条目等，当然还有很多很多控制权限，而这一切，恰好是MySQL的查询缓存无法提供的，MySQL的查询缓存相对客户端的缓存来说，真的是鸡肋。