何时使用 MySQL query_cache？

Question

直到最近，我一直将查询缓存视为提高查询性能的一个非常重要的工具。今天，我在听一个播客，讨论了将查询缓存调整为 0，并使用更好的内存缓存解决方案（例如 memcache.d）。

但他们也提到在某些情况下 query_cache 是有帮助的。因此，一般建议是按需启用它（使用SELECT SQL_CACHE, 和 query_cache_type = 2 配置设置）。

我的问题是，假设你有一个像 memcache.d 这样的缓存解决方案，什么类型的情况会使 query_cache 更优化？

编辑：添加链接

Answer 1

我认为那里有很多关于查询缓存的错误信息。

查询缓存的最佳情况是您必须检查大量行，但只将少数行返回给客户端。这种情况很常见的典型情况是系统没有应用适当的优化或索引。

在许多查询是主键查找或其他非常好的优化的情况下，查询缓存可能会导致负面的可伸缩性。是的：这让事情变得更糟！

这样做的原因是该设计增加了一些内部锁定，这限制了您的 MySQL 服务器在多核机器上的扩展。

查询缓存是 MySQL 中许多“突然停顿”的原因——并非所有问题都很明显。在 Percona Server 中，我们向进程列表添加了一个新状态（等待 Qcache 互斥锁）：http ://www.percona.com/docs/wiki/percona-server:features:status_wait_query_cache_mutex

（免责声明，我为 Percona 工作。）

Answer 2

Memcached（或Coherence）缓存整个结果集。数据库中的缓存缓存数据库行。因此，假设您有一个访问模式，其中查询是固定的并且数据很少更改（例如select * from restaurants where location='london'）。每次添加新餐厅时，您可能会运行该查询数千次，因此缓存整个结果集是有意义的，它可以节省每次访问数据库的时间 - 但您仍然拥有 RDBMS 和 SQL 的所有可管理性和灵活性（您只需要在数据发生变化的特殊情况下踢出缓存）。有人称这种参考数据或静态数据。

但是，假设您有一个临时访问模式（也许您的用户有很多选项可以准确找到他们今晚想吃的地方，但很少有两个用户具有完全相同的偏好）。然后您可能想要缓存行（以保存到磁盘）但在内存中即时组装每个结果集。那是您希望数据库本身管理它缓存的内容和方式的时候。在大多数情况下，混合或分层方法最有效。

请注意，还有第三种缓存在起作用——操作系统的文件系统缓存。我不喜欢这些，原因很简单，如果你从磁盘读取一个块，它现在存在于数据库缓存和文件系统缓存中，但数据库并不“知道”后者，所以它不能用它做任何聪明的事情，比如看看它的使用频率。从 DBA 的角度来看，系统上的任何空闲内存以及操作系统本身需要满意的内容都被浪费了。