MySQL Query Cache 機制詳解與 8.0 移除後的現代替代方案

MySQL 5.7 前的 Query Cache（QC）曾是「開啟即加速」的銀彈，但因嚴重鎖爭用、失效率高、無法擴展，已在 8.0 徹底移除。本文解析 QC 原理、關鍵指標判讀，並給出生產級替代架構。

QC 核心機制（歷史參考）

• Key：SQL 文本（區分大小寫、空格、註釋）+ 數據庫名 + 客戶端字符集 + SQL_CACHE 標誌。
• Value：結果集（含欄位元數據）。
• 失效觸發：相關表任意寫入（INSERT/UPDATE/DELETE/TRUNCATE/DDL） → 整表緩存失效。
• 鎖模型：全局互斥鎖保護緩存結構，高併發下成為熱點。

關鍵狀態變量判讀

配置調優經驗值（5.7 仍在用的實例）

query_cache_type = DEMAND  -- 顯式 SQL_CACHE 才緩存
query_cache_size = 64M     -- 別超 128M，越大鎖爭用越烈
query_cache_limit = 1M     -- 單查詢結果超 1M 不緩存
query_cache_min_res_unit = 4K  -- 減少碎片，但會增大內存佔用

判斷是否關閉：Qcache_hits / (Qcache_hits + Com_select) < 20% 且 Qcache_lowmem_prunes 高 → 關閉獲益更大。

現代替代架構：分層緩存體系

應用層緩存模式對比

• Cache-Aside（旁路）：應用讀 Redis → 未命中查 DB → 回寫 Redis。最通用，但雙寫一致性需雙刪/延遲雙刷/ Canal 異步同步。
• Read-Through / Write-Through：框架封裝，透明化緩存邏輯，適合統一基礎設施層。
• Write-Behind：寫入緩存異步落庫，高寫吞吐，但數據丟失風險需業務容忍。

遷移建議

1. 5.7 實例：query_cache_type=OFF、query_cache_size=0 徹底關閉，騰出內存給 Buffer Pool。
2. 梳理業務查詢熱點，按上表分層落地。
3. 建立緩存鑰匙命名規範、TTL 標準、監控大盤（命中率、穿透率、雪崩指標）。

Query Cache 退出歷史舞台，是因為「單機全局鎖」無法適應多核高併發時代。分層、分佈、異步，才是現代緩存架構的正解。