sha*_*ihe 19 mysql query-cache mysql-8.0
为什么 MySQL 在 8.0 版本之后去掉了查询缓存功能？
dan*_*ack 16
MySQL 服务器团队有一篇关于此的详细博客，其中 Matt Lord 说：
自 MySQL 5.6 (2013) 以来，查询缓存已被默认禁用，因为众所周知，它不会随着多核机器上的高吞吐量工作负载而扩展。
我们考虑了我们可以对查询缓存进行哪些改进，以及我们可以对所有工作负载进行改进的优化。
虽然这些选择本身是正交的，但工程资源是有限的。也就是说，我们正在改变策略以投资于更普遍适用于所有工作负载的改进。
Rol*_*DBA 11
甩掉包袱 ！！！
对于大多数数据库开发人员来说，正确估计其应用程序中最常见结果集的大小是一项挑战。拥有一个大的查询缓存只是一个很大的绷带。
有一个更大的原因预示了查询缓存的消亡：四年前（June 07, 2014），我回答了为什么从 MySQL 5.6 开始默认禁用 query_cache_type的帖子？. 简而言之，查询缓存一直在检查 InnoDB 缓冲池的变化。您可以在High Performance MySQL (2nd Edition) 的第 209-215 页上找到它。
这些年来我提到了这一点：
Sep 05, 2012：频繁查询缓存失效的开销值得吗？Sep 25, 2013：使查询缓存条目（键）无效Sep 26, 2013：查询缓存命中值在我的数据库中没有改变Dec 23, 2013:高 CPU 和内存使用率的 MySQL（我同意另一个答案，但这是我 2 美分的价值。）
实施后，...
QC不能与 Galera 或 Group Replication 一起使用，这两者在 HA 领域都越来越受到关注。
当query_cache_size它变大时，它的效率就会降低。这是由于“修剪”效率低下。（注意：Aurora 重新实现了它，并且似乎已经解决了这个问题。）
每个都有 开销，SELECT因为它不知道 QC 是否会起作用。几十年前，这一比例估计为 11%。直到摆脱QC的，唯一的解决方法是做既 query_cache_size = 0 与 query_cache_type = 0在配置文件中。（很少有人意识到两者都需要。）
在典型的生产服务器中，插入频繁发生。由于每次插入都会导致对该表的所有条目进行修剪，因此 QC 对于此类表实际上毫无用处。
在我为性能问题审查过的数百个系统中，也许 95% 没有 QC 会更好。