为什么MySQL在版本8.0之后删除查询缓存功能？

Question

为什么MySQL在版本8.0之后删除查询缓存功能？

Answer 1

关于这一点有一个详细的来自MySQL服务器团队的博客，马特·洛德说：

自MySQL 5.6 (2013年)以来，查询缓存已被默认禁用，因为众所周知，在多核计算机上不使用高吞吐量工作负载进行扩展。我们考虑了可以对查询缓存进行哪些改进，而可以进行哪些优化，从而为所有工作负载提供改进。虽然这些选择本身是正交的，但工程资源是有限的。也就是说，我们正在改变战略，投资于更普遍适用于所有工作量的改进。

Answer 2

好解脱！

对于大多数数据库开发人员来说，正确估计应用程序中最常见的结果集的大小是一个挑战。拥有一个大型查询缓存只是一个很大的包扎。

还有一个更大的原因预示了查询缓存的消亡:四年前(June 07, 2014)，我回答了post 为何查询？_缓存_默认情况下，类型从MySQL 5.6开始禁用吗？。简而言之，查询缓存总是检查InnoDB缓冲池中的更改。你可以在高性能MySQL第209-215页(第二版)上找到这个。

这些年来我都提到过：

• Sep 05, 2012：频繁查询缓存失效的开销值得吗？
• Sep 25, 2013：使查询缓存项无效(键)
• Sep 26, 2013：查询缓存命中值在我的数据库中没有变化。
• Dec 23, 2013：具有高和内存使用率的MySQL

RIP查询缓存！

Answer 3

(我同意另一个答案，但这是我的2美分价值。)

随着实施，..。

• QC不能与Galera或Group复制一起工作，这两种复制在HA领域都得到了更多的支持。
• 当query_cache_size变得大的时候，它的效率就降低了。这是因为“修剪”效率低下。(注: Aurora重新实现了它，并且似乎已经解决了这个问题。)
• 每个SELECT都有一个开销，因为它不知道QC是否会发挥作用。几十年前，这一比例估计为11%。在摆脱QC之前，唯一的解决办法是在配置文件中同时执行query_cache_size = 0和query_cache_type = 0。(很少有人意识到两者都是需要的。)
• 在典型的生产服务器中，插入经常发生。由于每一次插入都会导致对该表的所有条目进行删减(S)，因此QC实际上对此类表格毫无用处。
• 也许，在我对性能问题进行审查的数百个系统中，95%的系统在没有QC的情况下会更好。