MySQL 查詢快取深度解析：配置參數、狀態監控、失效機制與最佳實踐

MySQL Query Cache（查詢快取）曾是讀多寫少場景的性能利器，但因鎖競爭嚴重、無法利用多核、8.0 移除等原因，現已淡出主流。本文完整記錄其配置參數、狀態變量、失效觸發條件、監控指標與遷移建議，供維護舊版本（5.6/5.7）系統的 DBA 參考，並說明為何新架構應棄用轉用 Redis/應用層快取。

核心配置參數

SHOW VARIABLES LIKE 'query_cache%';

SQL 級控制

-- 明確不快取
SELECT SQL_NO_CACHE * FROM huge_table;

-- 明確快取（type=2 時生效）
SELECT SQL_CACHE * FROM lookup_table;

狀態監控指標

SHOW STATUS LIKE 'Qcache%';

命中率計算

Hit Rate = Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached)
-- 理想 > 80%，讀多寫少場景可達 90%+

快取失效觸發條件（關鍵）

以下操作會使**相關表的所有快取條目失效**：

• INSERT、UPDATE、DELETE、REPLACE
• TRUNCATE TABLE
• ALTER TABLE、DROP TABLE、DROP DATABASE
• GRANT、REVOKE（權限變更）
• FLUSH TABLES

寫入頻繁的表不適合開啟 Query Cache，每次寫入都要獲取全域鎖遍歷失效相關快取，嚴重阻塞並發。

快取結構與記憶體分配

• 每個查詢佔用：1 個查詢文本塊 + N 個結果塊（每塊 query_cache_min_res_unit，最後一塊釋放餘量）
• 每張表首次被快取時，額外佔用 1 個表信息塊
• 碎片整理：FLUSH QUERY CACHE 整理空閒塊，不清除有效快取；RESET QUERY CACHE 完全清空

為何 8.0 移除 Query Cache？

1. 全域互斥鎖：任何讀/寫快取操作需持有全域鎖，多核 CPU 利用率極低
2. 失效開銷大：寫入需掃描並失效所有相關快取，寫入延遲不可控
3. 命中率低：生產環境常見 < 20%，維護成本 > 收益
4. 無法快取預存語句：Prepared Statement 不支援
5. 更好的替代方案：Redis、應用層快取、ProxySQL、物化視圖