MySQL 查詢緩存機制深度解析與優化策略

一、查詢緩存的適用場景

MySQL 查詢緩存將 SELECT 語句文本及其結果集存放於記憶體，適用於「讀多寫少、數據變動頻率低」的表。典型場景如產品目錄、靜態配置表等。若表頻繁更新（如訂單、日誌表），緩存會頻繁失效，反而增加開銷。

二、查詢緩存的限制條件

1. 表數據變更即失效：任何 INSERT/UPDATE/DELETE 都會清空該表相關緩存。
2. 不支援預處理語句與存儲函數：含用戶自定義函數、變量、系統表引用的查詢不緩存。
3. SQL 文本必須完全一致：大小寫、空格、註釋、條件順序皆需完全相同才命中。例如 SELECT * FROM t 與 select * from t 視為不同查詢。
4. 不緩存不確定性函數：如 NOW()、RAND()、UUID() 等。

三、提升緩存命中率的實戰策略

1. 按數據變動頻率拆表

將高頻更新欄位（如庫存量）移至獨立表，核心屬性（如商品名、規格）留在主表。主表緩存不再因庫存更新而失效。

2. 統一 SQL 編寫規範

• 全項目統一關鍵字大小寫（建議全大寫）。
• 固定欄位順序、條件順序。
• 前台查詢預設條件盡量一致，避免個性化導致 SQL 碎片化。

3. 適當調大 query_cache_size

緩存空間不足會導致舊條目被淘汰。根據業務量級將 query_cache_size 設為 64MB~256MB 甚至更大，並監控 Qcache_lowmem_prunes 指標。

四、查看緩存狀態

SHOW VARIABLES LIKE 'query_cache%';
SHOW STATUS LIKE 'Qcache%';

重點關注 query_cache_type 是否為 ON、Qcache_hits / Qcache_inserts 比值（命中率）。