Mysql|[译文-MySQL开发团队的文章] MySQL 8.0（不再支持查询缓存） Mysql|mysql

原文链接:MySQL 8.0: Retiring Support for the Query Cache
MySQL 8.0：不再支持查询缓存时间：2017年5月30日
作者：MySQL Matt Lord
正如Rene昨天在ProxySQL博客上写道：

尽管MySQL查询缓存旨在提高性能，但它具有严重的可伸缩性问题，并且很容易成为严重的瓶颈。

这确实是我们在MySQL团队中观察到一段时间的事情。在我们讨论今天的帖子之前，让我开始介绍。
查询缓存简介 MySQL查询缓存是缓存的查询结果。它将以SEL开头的传入查询与哈希表进行比较，如果匹配，则返回上一次查询的结果。有一些限制：

查询必须逐字节匹配（查询缓存避免解析）
使用非确定性功能将导致查询不被缓存（包括临时表，用户变量，RAND（），NOW（）和UDF）。
查询缓存被设计为不提供过时的结果。对基础表的任何修改都会导致这些表的所有缓存无效。
对于是否可以将缓存用于InnoDB，存在一些限制（为了尊重MVCC；当您打开事务时，“缓存”可能无法在您期望的视图中表示数据。）

查询缓存使用的理想场景正如我几年前在个人博客中写道：

查询高速缓存的理想方案通常是只读的。其中有许多非常昂贵的查询，它们检查数百万行而仅返回几行。假设有网页上表单的下拉值需要一个复杂的查询来获取数据。在这种情况下，查询缓存可以掩盖由于缺少索引而导致的性能问题，这对新手用户很有帮助。

这个想法在今天仍然是正确的。但是我认为重要的是还要指出，我们现在已经有很多DBA工具的对这些性能有所改善：

在MySQL服务器中，我们现在可以重写查询以插入提示（或进行其他修改以提高性能）。
我们有像ProxySQL这样的第三方工具，它们可以充当中间人查询缓存。ProxySQL还支持缓存的TTL，在我之前提供的示例中可以正常工作（获取下拉值）。

查询缓存的局限性自从MySQL 5.6（2013）以来，查询缓存已被禁用，因为它已知在多核机器上不能与高吞吐量工作负载的规模相比较。 Rene昨天在他的帖子中证实了这一点，而且这个问题之前也曾被Stewart Smith和Domas Mituzas（更新：Kristian Koehntopp）提及。
假设可伸缩性可以提高，那么查询缓存的限制因素在于，由于只有命中缓存的查询才会得到改善；它不太可能提高性能的可预测性。对于面向用户的系统，降低性能的差异通常比提高峰值吞吐量更为重要：

Mysql|[译文-MySQL开发团队的文章] MySQL 8.0（不再支持查询缓存）

文章图片

文章图片

决定取消对查询缓存的支持我们赞同密歇根大学安娜堡分校佳敏黄，巴尔赞Mozafari，格兰特Schoenebeck，托马斯F. Wenisch的研究成果。我们考虑了两种方案：一个是我们可以对查询缓存进行哪些改进的方案，另一个是我们可以做出哪些改进，从而为所有工作负载提供改进。
尽管这些选择本身是正交的，但资源是有限的。也就是说，我们正在转移策略，以投资于更普遍适用于所有工作负载的改进。
我们也同意Rene的结论，即当缓存靠近客户时，缓存会带来最大的好处：

文章图片

将缓存移到客户端时，“Client + 2x ProxySQL”结果显示性能提升了5.2倍。
使用查询缓存用户的升级路径考虑到当前的局限性，在MySQL 5.7的生存期内将继续支持查询缓存。MySQL 8.0将不支持查询缓存，并且鼓励用户升级以使用服务器端查询重写或ProxySQL作为中间人缓存。
我们希望此更改仅影响少数用户，但是如果您对此感到担心，请联系并取得联系！
【Mysql|[译文-MySQL开发团队的文章] MySQL 8.0（不再支持查询缓存）】感谢您使用MySQL！