我們已經升級到 MySQL 5.6 並開始看到 db server 的負載顯著增加，最後發現 query_cache_type從 5.6 開始預設為 off。

我們再次啟用它並看到負載減少，為什麼從 MySQL 5.6 開始預設禁用此值？我看不到啟用它的問題。

您需要了解 InnoDB 的歷史才能了解原因。它是這樣的：

戰爭故事

InnoDB 和查詢記憶體一直處於戰爭狀態。InnoDB 在檢查 InnoDB 緩衝池中的更改然後交叉檢查查詢記憶體以查找相同的更改時往往會非常嚴厲。

和平條約

在 MySQL 5.0 之前，InnoDB 禁用了查詢記憶體。現在，InnoDB 與之互動。為簡化問題，您可以通過將query_cache_size設置為 0 來禁用查詢記憶體。

根據關於 query_cache_time 的 MySQL 文件

如果伺服器在query_cache_type設置為 0 的情況下啟動，則根本不會獲取查詢記憶體互斥體，這意味著在執行時無法啟用查詢記憶體，從而減少了查詢執行的成本。

投降條款

將query_cache_size設置為 0 並不是一種萬能的解決方案。

首先，戰爭的原因是成本。InnoDB 將始終檢查更改。更大的查詢記憶體將使 InnoDB 更難工作。禁用查詢記憶體讓 InnoDB 和查詢記憶體感到高興。但是，即使有這樣的和平條約，您（開發人員/DBA）也可能因查詢性能不佳而成為這場戰爭的犧牲品。

取決於以下

• 工作量
• 變更頻率
• 讀取相同數據的頻率

您應該將query_cache_size設置為您認為可以提高性能的任何數字（這無異於開始地下運動）。

結語

如果你想知道我在哪裡想出了這個戰爭故事，請參閱我的舊文章

• Sep 05, 2012:頻繁查詢記憶體失效的成本值得嗎？

仔細閱讀它，因為我從高性能 MySQL（第 2 版）的第 209-215 頁學到了這一點

我之前建議對其他人禁用查詢記憶體

• Sep 25, 2013:使查詢記憶體條目無效（鍵）
• Sep 26, 2013：查詢記憶體命中值在我的數據庫中沒有改變
• Dec 23, 2013:具有高 CPU 和記憶體使用率的 MySQL

**注意：**我意識到問題是關於query_cache_type的。它確實對查詢記憶體有影響。禁用記憶體會削弱 InnoDB 對其的支配地位。手動設置query_cache_type只是強制開發人員/DBA 仔細考慮查詢記憶體將遇到的查詢類型。

我有一篇博文解釋為什麼會出現在這裡。

簡短版本： 查詢記憶體會導致多核機器上的可伸縮性問題。所以現在預設禁用。

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