MySQL Query Cache 深度解析：原理、配置、監控與適用場景

前言：像荔枝一樣的「雙刃劍」

Query Cache 直接緩存 SELECT 結果集與 SQL 文本，命中時繞過解析、優化、執行，極大提升讀取效能。但它有全局鎖、碎片、失效機制等副作用，濫用反拖垮效能。本文從五個維度系統梳理。

一、工作原理

• 緩存 SELECT/預處理查詢（5.1.17+）的結果集 + SQL 文本
• 新查詢先查緩存，**完全匹配（含大小寫、空白、註解）** 才命中

不可緩存的查詢類型

• 含 SQL_NO_CACHE、不確定函數 (NOW(), RAND(), UUID() 等)
• 系統庫 (mysql, information_schema)、臨時表、SELECT ... INTO
• 事務隔離級別 SERIALIZABLE、含 LOCK IN SHARE MODE/FOR UPDATE
• 使用用戶變量、預處理變量、存儲過程局部變量
• 有警告、無表引用、僅列級權限的查詢

二、核心配置參數

三、維護操作

• FLUSH QUERY CACHE：整理碎片（不清空資料）
• RESET QUERY CACHE / FLUSH TABLES：完全清空緩存區

四、效能監控關鍵指標

碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
記憶體使用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
低記憶體修剪次數 = Qcache_lowmem_prunes (LRU 淘汰計數)

調優決策樹

• 命中率 > 80% + 使用率 > 80% + Qcache_lowmem_prunes 持續增長 → 擴大 query_cache_size
• 命中率 < 40% + Qcache_lowmem_prunes 平穩 → 縮小或關閉，業務重複查詢少
• 觀察 freeing items 狀態頻繁 → 鎖競爭嚴重，考慮關閉

最小分配單元校準公式

query_cache_min_res_unit ≈ (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

五、適用業務場景

• ✅ **讀多寫少**：門戶、新聞、報表、論壇、靜態配置表
• ✅ 表 DML 頻率低，配合 query_cache_type=2 + SQL_CACHE 精準控制
• ❌ **寫入頻繁、高併發 OLTP**：緩存失效頻繁、全局鎖競爭、碎片整理開銷大
• ❌ 大結果集、非確定性函數、高基數查詢

版本註記

MySQL 5.7 開始棄用 Query Cache，8.0 **完全移除**。新架構請改用 Redis、ProxySQL、應用層緩存等方案。