您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 資料庫相關知識

MySQL 查詢緩存完整指南：配置、監控、失效機制與 FLUSH 命令詳解

編輯：MySQL 資料庫相關知識

MySQL 查詢緩存曾是提升讀密集型應用效能的利器（MySQL 5.7 仍支援，8.0 已移除）。本文詳細記錄查詢緩存的配置參數、啟用驗證、命中率監控、失效條件、記憶體管理與碎片整理，以及 FLUSH 系列命令的完整用法與應用場景。

一、查詢緩存工作原理

緩存 SQL 文本（區分大小寫、空格、註釋） 與 查詢結果集 的映射。
收到相同 SQL 時，直接返回緩存結果，跳過解析、優化、執行。
表結構或資料變更（INSERT/UPDATE/DELETE/TRUNCATE/ALTER/DROP）導致該表相關緩存失效。

二、配置參數詳解

修改 my.cnf [mysqld] 區段：

[mysqld]
query_cache_type = 1        # 0=OFF, 1=ON, 2=DEMAND
query_cache_size = 64M      # 總記憶體大小，必須 1024 倍數
query_cache_limit = 2M      # 單次查詢結果最大緩存大小
query_cache_min_res_unit = 4K  # 最小記憶體塊大小

query_cache_type 三種模式

值	行為
`0 / OFF`	關閉查詢緩存
`1 / ON`	緩存所有 `SELECT`，除非用 `SQL_NO_CACHE` 提示
`2 / DEMAND`	僅緩存帶 `SQL_CACHE` 提示的 `SELECT`

三、驗證與監控指標

SHOW VARIABLES LIKE '%query_cache%';

SHOW STATUS LIKE 'Qcache%';

關鍵狀態變數解讀

變數	含義	健康判斷
`Qcache_hits`	緩存命中次數	持續增長為佳
`Qcache_inserts`	緩存寫入次數	—
`Qcache_hits / Qcache_inserts`	命中/寫入比	> 3:1 視為有效，> 10:1 為優秀
`Qcache_lowmem_prunes`	記憶體不足被淘汰次數	持續增長 = 記憶體不足或碎片嚴重
`Qcache_free_blocks`	空閒記憶體塊數	過大 = 碎片多
`Qcache_free_memory`	剩餘記憶體	—
`Qcache_not_cached`	未緩存查詢數（非 SELECT、含不確定函數等）	—
`Qcache_queries_in_cache`	當前緩存查詢數	—
`Qcache_total_blocks`	總記憶體塊數	—

四、緩存失效條件（重要）

表結構/資料異動：INSERT/UPDATE/DELETE/TRUNCATE/ALTER TABLE/DROP TABLE/DROP DATABASE
查詢含不確定函數：NOW()、RAND()、UUID()、CURRENT_DATE() 等
查詢使用 SQL_NO_CACHE 提示
query_cache_type = 0 或 DEMAND 模式下無 SQL_CACHE
結果集大小超過 query_cache_limit
事務期間（InnoDB）：修改表的事務提交前，該表緩存不可用
表被鎖定（LOCK TABLES）時，視 query_cache_wlock_invalidate 設定

五、記憶體管理與碎片整理

緩存區劃分為固定大小塊（query_cache_min_res_unit，預設 4KB）。
查詢開始前預分配塊，結果寫入；結束時釋放多餘空間 → 產生碎片。
整理碎片： FLUSH QUERY CACHE（不清除現有緩存，僅整理碎片，期間阻塞其他連接使用緩存）。
清空緩存： RESET QUERY CACHE。

六、FLUSH 命令完整速查表

命令	作用	常用場景	是否寫入 Binlog
`FLUSH HOSTS`	清空主機緩存表	主機 IP 變更、`Host ... is blocked` 錯誤	是
`FLUSH LOGS`	關閉當前 binlog，啟動新檔案	備份前切割日志	否
`FLUSH PRIVILEGES`	重新載入授權表到緩存	手動修改 `mysql.user` 後生效	是
`FLUSH TABLES`	關閉所有打開表，清空查詢緩存	DDL 操作前、備份鎖表前	是
`FLUSH TABLES WITH READ LOCK`	關閉表 + 全庫讀鎖	邏輯備份（mysqldump --single-transaction 除外）	否
`FLUSH STATUS`	重置大多數狀態變數	基準測試前重置計數器	是
`FLUSH QUERY CACHE`	整理查詢緩存碎片	碎片率高時定期執行	是
`RESET MASTER`	刪除所有 binlog，重置索引	重新搭建主從、清理測試環境	否
`RESET SLAVE`	從庫忘記主庫位置，刪除 relay log	重新配置主從複制	否

七、效能調優建議

讀多寫少場景（配置表、字典表、靜態報表）開啟 query_cache_type=1，設 query_cache_size=64M~256M。
寫入頻繁表 禁用緩存（SQL_NO_CACHE 或表級禁用），避免頻繁失效帶來的鎖競爭與 CPU 開銷。
監控 Qcache_lowmem_prunes：持續增長 → 擴大 query_cache_size 或調大 query_cache_min_res_unit（大結果集場景）。
MySQL 8.0+ 已移除查詢緩存：建議改用 Redis、應用層緩存、或 PreparedStatement 復用執行計畫。