shaoyihe Asked: 2018-09-14 17:38:16 +0800 CST2018-09-14 17:38:16 +0800 CST 2018-09-14 17:38:16 +0800 CST MySQL 8.0 之后为什么去掉了查询缓存功能？ 772 MySQL 8.0 之后为什么去掉了查询缓存功能？ mysql query-cache 3 个回答 Voted Best Answer danblack 2018-09-14T17:42:19+08:002018-09-14T17:42:19+08:00 MySQL 服务器团队有一篇关于此的详细博客，Matt Lord 说： 自 MySQL 5.6 (2013) 以来，查询缓存已默认禁用，因为众所周知，它无法在多核机器上随高吞吐量工作负载进行扩展。 我们考虑了可以对查询缓存进行哪些改进，以及可以对所有工作负载进行哪些优化。 虽然这些选择本身是正交的，但工程资源是有限的。也就是说，我们正在转变战略，投资于更普遍适用于所有工作负载的改进。 RolandoMySQLDBA 2018-09-14T17:52:58+08:002018-09-14T17:52:58+08:00 甩掉包袱 ！！！ 对于大多数数据库开发人员来说，正确估计其应用程序中最常见结果集的大小是一个挑战。拥有一个大的查询缓存只是一个大绷带。 有一个更大的原因预示了查询缓存的消亡：四年前（June 07, 2014），我回答了为什么 query_cache_type 从 MySQL 5.6 开始默认禁用？. 简而言之，查询缓存一直在检查 InnoDB 缓冲池的变化。您可以在High Performance MySQL (2nd Edition) 的第 209-215 页上找到它。 这些年来，我提到了这一点： Sep 05, 2012:频繁查询缓存失效的开销值得吗？ Sep 25, 2013:使查询缓存条目无效（键） Sep 26, 2013：查询缓存命中值在我的数据库中没有改变 Dec 23, 2013:具有高 CPU 和内存使用率的 MySQL RIP 查询缓存！！！ Rick James 2018-10-06T13:54:24+08:002018-10-06T13:54:24+08:00 （我同意另一个答案，但这是我的 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 的情况下会更好。
MySQL 服务器团队有一篇关于此的详细博客，Matt Lord 说：
甩掉包袱 ！！！
对于大多数数据库开发人员来说，正确估计其应用程序中最常见结果集的大小是一个挑战。拥有一个大的查询缓存只是一个大绷带。
有一个更大的原因预示了查询缓存的消亡：四年前（
June 07, 2014），我回答了为什么 query_cache_type 从 MySQL 5.6 开始默认禁用？. 简而言之，查询缓存一直在检查 InnoDB 缓冲池的变化。您可以在High Performance MySQL (2nd Edition) 的第 209-215 页上找到它。这些年来，我提到了这一点：
Sep 05, 2012:频繁查询缓存失效的开销值得吗？Sep 25, 2013:使查询缓存条目无效（键）Sep 26, 2013：查询缓存命中值在我的数据库中没有改变Dec 23, 2013:具有高 CPU 和内存使用率的 MySQLRIP 查询缓存！！！
（我同意另一个答案，但这是我的 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 的情况下会更好。