MySQL Query Cache 深度解析：為什麼高併發下建議關閉？

MySQL Query Cache 深度解析：為什麼高併發下建議關閉？

基於 Percona 官方測試與社區實戰經驗，本文剖析 Query Cache 的全局鎖爭用機制、命中收益與併發代價的權衡，給出生產環境配置建議。

核心架構缺陷：全局互斥鎖

Query Cache 的讀寫操作均需獲取全局 mutex，導致所有訪問串行化。這在 15 年前單核時代可接受，但在現代多核服務器上成為性能殺手：

「任何讀寫操作都必須獲得全局鎖，意味著所有訪問都被串行化。這在當今多核服務器上是扼殺性能的最佳方式。」 —— Percona

命中收益 vs. 併發代價

• 命中極快：緩存命中僅需幾十微秒，比 InnoDB 主鍵查詢（數百微秒）快一個數量級
• 未命中開銷大：未命中仍需加鎖檢查，且寫入時需失效相關緩存
• 高併發下鎖爭用劇烈：Select 併發越高，mutex 等待越久，吞吐量反而下降

實測數據證明

Percona 測試與社區驗證一致表明：

• 關閉 Query Cache 後，MySQL 併發能力與吞吐量顯著提升
• 增大 query_cache_size 無改善，甚至惡化（鎖競爭更激烈）
• 僅在極低併發、高重複查詢場景（如配置表、字典表）有微弱收益

專家建議配置策略

1. 默認關閉：query_cache_type = OFF、query_cache_size = 0
2. 極少數只讀場景可開 1MB：query_cache_size = 1M，更大無意義
3. 替代方案：
   • 應用層緩存：Redis、Memcached
   • InnoDB Buffer Pool 擴大：缓存熱點索引與數據頁
   • Prepared Statement + 客戶端緩存

關於 Key Buffer 的補充

社區討論指出 key_buffer_size 需設定為能容納所有索引的大小（僅對 MyISAM 生效），InnoDB 依賴 innodb_buffer_pool_size。兩者不可混淆。

結論

Query Cache 是典型的「看似美好、實則有害」特性。除非極確定業務為低併發高重複只讀，否則生產環境請堅決關閉，將資源投入 Buffer Pool 與應用層緩存。