MySQL 查詢緩存內存管理機制深度解析：塊分配、碎片整理、事務影響

查詢緩存開銷

• 讀取前必須檢查緩存（CPU 消耗）。
• 結果寫入緩存需分配內存塊、複製數據（延遲）。
• 失效判邏輯（表變更導致相關緩存失效）增加開銷。

但命中時極快，**整體收益通常大於成本**。

不緩存的情況（即使用 SQL_CACHE）

• 包含用戶自定義函數（UDF）
• 引用用戶變量（@var）
• 調用存儲過程/函數
• 含實時函數：NOW()、RAND()、UUID() 等
• 引用臨時表
• 查詢結果過大（超過 query_cache_limit）

內存塊管理

• 緩存池啟動時分配一大塊（query_cache_size - 40KB 元數據）。
• 每次緩存結果分配一塊，**最小單位 query_cache_min_res_unit（默認 4KB）**。
• 邊產生邊寫入：結果集分塊存儲，避免預估大小失誤。
• 塊滿則分配新塊，形成鏈表；寫完後**修剪尾部空閒空間**歸還池中。
• 長期運行產生碎片，需 FLUSH QUERY CACHE 整理（MySQL 5.7.20 移除查詢緩存，8.0 徹底移除）。

事務引擎影響

InnoDB 事務未提交前，修改的數據對其他事務不可見，但查詢緩存**不感知事務隔離**，可能導致：

• 事務 A 修改表 → 緩存未失效（因未提交）
• 事務 B 讀取緩存 → 見到舊數據（髒讀風險）

MySQL 通過**表級鎖**在事務提交時失效相關緩存，但並發高時仍有窗口期。建議高併發寫入場景**關閉查詢緩存**（query_cache_type=OFF）。

關鍵配置