mysql - 为什么我会收到 lowmen prunes 的通知，即使一半的查询缓存没有被使用？

Question

我正在使用一个监控系统，该系统每隔几个小时就会报告有很多低内存修剪

2013 年 12 月 5 日星期四 01:21:52 UTC 7347 查询缓存 lowmem 修剪在 600 秒内(12.24/秒)

2013 年 12 月 5 日星期四 10:21:52 UTC 600 秒内 10596 次查询缓存 lowmem 修剪(17.66/秒)

2013 年 12 月 5 日星期四 11:26:52 UTC 600 秒内 8979 次查询缓存 lowmem 修剪(14.96/秒)

mysql> SHOW STATUS LIKE 'Qc%';
Variable_name            Value
Qcache_free_blocks       2250
Qcache_free_memory       6938840
Qcache_hits              578811080
Qcache_inserts           331501709
Qcache_lowmem_prunes     124066063
Qcache_not_cached        135977294
Qcache_queries_in_cache  5638
Qcache_total_blocks      13625

我的 16MB 查询缓存中大约有 6MB 没有被使用

mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| query_cache_size | 16777216 |
+------------------+----------+
1 row in set (0.00 sec)

为什么在没有填满缓存的情况下修剪查询？

我应该增加还是减少缓存大小？

附加信息

mysql> FLUSH STATUS;

30分钟后

mysql> SHOW STATUS LIKE '%Qcache%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| Qcache_free_blocks      | 1935    |
| Qcache_free_memory      | 5154904 |
| Qcache_hits             | 43918   |
| Qcache_inserts          | 33074   |
| Qcache_lowmem_prunes    | 4443    |
| Qcache_not_cached       | 10438   |
| Qcache_queries_in_cache | 6276    |
| Qcache_total_blocks     | 14713   |
+-------------------------+---------+
8 rows in set (0.00 sec)

Answer 1

当任何 INSERT/UPDATE/DELETE 语句修改关联表中的数据时，查询缓存会使条目过期。这不会等待缓存填满。

http://dev.mysql.com/doc/refman/5.6/en/query-cache-operation.html说:

If a table changes, all cached queries that use the table become invalid and are removed from the cache. This includes queries that use MERGE tables that map to the changed table. A table can be changed by many types of statements, such as INSERT, UPDATE, DELETE, TRUNCATE TABLE, ALTER TABLE, DROP TABLE, or DROP DATABASE.

---

关于你的问题:

If using InnoDB and the insertion is at the end of a table, does the query cache expire entries?

是的，没错。例如，查询缓存条目与查询 SELECT COUNT(*) FROM mytable 相关联。插入到 mytable 的末尾将使该查询的缓存结果无效。

查询缓存在决定给定的数据更改是否影响缓存条目方面没有太多智能。它假定如果您更改表中的任何内容，则必须丢弃缓存中以任何方式与该表关联的所有查询。

只有当缓存的结果在插入后发生变化时，它才能应用更多的智能来丢弃某些查询结果。但它会怎么做呢？它必须在插入后再次运行查询，将结果与存储在缓存中的结果进行比较。如果不同，则替换缓存中的结果。

但它必须对缓存中的每个 查询结果执行此操作。请注意，您的状态输出显示您的查询缓存中有 5638 个查询。当然，并非所有这些都与您要插入的同一个表相关联，但我们可以假设其中有许多是。

单个 INSERT 导致重新执行数百或数千个 SELECT 语句以刷新其缓存结果并不是一个好的权衡。

因此折衷方案是对表的更改会清除与该表关联的所有缓存结果，即使这不是绝对必要的。

---

因此，查询缓存并不是一种非常精确的缓存查询的方法。它对某些工作负载很有帮助，例如，如果您的应用程序倾向于多次重复给定的查询，而表没有收到任何更改。但是we已经看到许多情况下，工作负载使查询缓存没有帮助，在某些情况下，维护查询缓存的开销实际上会损害性能。

如果你想要一些更精确的缓存机制，你必须在你的应用程序中自己编写代码，将某些结果保存到 memcached 或类似的快速内存缓存中。然后，您有责任在数据更改时跟踪哪些条目需要刷新。