Mysql8查询缓存_【译文】mysql8.0:退出对查询缓存的支持

Author:Morgan Tocker(the Product Manager for the MySQL Server)

前言

正如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)提及。

假设可扩展性可以提高，查询缓存的限制因素在于，只有查询命中了的缓存才能看到改进; 它不太可能提高性能的可预测性。 对于面向用户的系统，降低性能的可变性通常比提高峰值吞吐量更重要：

决定删除对查询缓存的支持

我们赞同University of Michigan, Ann Arbor大学的Jiamin Huang，Barzan Mozafari，Grant Schoenebeck，Thomas F. Wenisch的研究成果。 我们考虑了两种方案：一个是我们可以对查询缓存进行哪些改进的方案，另一个是我们可以做出哪些改进，从而为所有工作负载提供改进。

虽然这些选择本身是正交的，但工程资源是有限的。也就是说，我们要改变战略，去把资源投资到能够普遍适用于所有工作负载的改进上来。

我们也同意Rene的结论，即缓存在靠近客户端时提供了最大的好处

将缓存移到客户端时，“Client + 2x ProxySQL”结果显示性能提升了5.2倍。

现有用户的升级路径

根据当前的提示说明，查询缓存在MySQL 5.7一下版本仍然会继续得到支持。 但MySQL 8.0不再支持查询缓存，用户升级将被鼓励使用服务器端查询重写或ProxySQL作为中间缓存

我们预计这种变化只会影响到少数用户，但如果您关心此问题，请联系并联系！

感谢您使用MySQL！！