MySQL 查詢記憶體統計 - 為什麼 Qcache_lowmem_prunes 很高？

我有以下查詢記憶體設置

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 32M

跑了一整天后，我有以下統計數據

mysql> show global status like 'qca%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 66       |
| Qcache_free_memory      | 30462784 |
| Qcache_hits             | 1995904  |
| Qcache_inserts          | 2197056  |
| Qcache_lowmem_prunes    | 531214   |
| Qcache_not_cached       | 40683    |
| Qcache_queries_in_cache | 1429     |
| Qcache_total_blocks     | 2946     |
+-------------------------+----------+
8 rows in set (0.00 sec)

是Qcache_lowmem_prunes比較高，但Qcache_free_memory也高，是什麼原因？有沒有辦法通過調整上述配置來獲得高命中率？

記憶體的查詢結果可能因為記憶體耗盡而被驅逐，也可能因為記憶體查詢結果所基於的表中的數據已更新而被驅逐。

例如，您有許多單獨的查詢結果儲存在查詢記憶體中，用於以下查詢：

SELECT * FROM mytable WHERE id = 1;
SELECT * FROM mytable WHERE id = 2;
SELECT * FROM mytable WHERE id = 3;
SELECT * FROM mytable WHERE id = 4;
...
SELECT * FROM mytable WHERE id = 6060842;

不時會出現一些 lomem prunes，因為查詢記憶體的記憶體已滿。

然後有人去該表中插入一個新行。

所有依賴於該表的查詢結果都會立即從查詢記憶體中清除。因此，現在有很多空閒記憶體在不久之前就已滿。

其中一些需要除以Uptime才能有用。的典型值Qcache_lowmem_prunes/Uptime約為每秒 5 次。

另一個有趣的指標是Qcache_lowmem_prunes/Qcache_inserts，對於您的情況，它是 24%。那是有點高，表明QC不是很有效。

請記住，對錶的每次修改都會導致該表的所有QC 條目被清除。如果有很多清除，QC 可能會花費更多的精力而不是收益。

大多數應用程序的寫入次數過多，無法使 QC 值得擁有。

一個折衷方案是設置query_cache_type = DEMAND 和自由使用SQL_CACHE並SQL_NO_CACHE避免一些浪費的 QC 活動。

這些也很有用：

Qcache_not_cached / (Qcache_hits + Com_select + Qcache_not_cached)

Qcache_hits / Qcache_inserts -- Your value is <1, meaning the QC is not very useful

請注意，QC 已在 8.0 中刪除，並且不適用於任何集群設置。

引用自：https://dba.stackexchange.com/questions/294448