Query Cache(查詢緩存,以下簡稱QC)存儲SELECT語句及其產生的數據結果,特別適用於:頻繁提交同一個語句,並且該表數據變化不是很頻繁的場景,例如一些靜態頁面,或者頁面中的某塊不經常發生變化的信息。QC有可能會從InnoDB Buffer Pool或者MyISAM key buffer裏讀取結果。
由於QC需要緩存最新數據結果,因此表數據發生任何變化(INSERT、UPDATE、DELETE或其他可能產生數據變化的操作),都會導致QC被刷新。
根據MySQL官方的測試,QC的優劣分別是:
1、如果對一個表執行簡單的查詢,但每次查詢都不一樣的話,打開QC後,性能反而下降了13%左右。但通常實際業務中,通常不會只有這種請求,因此實際影響應該比這個小一些。 2、如果對一個只有一行數據的表進行查詢,則可以提升238%,這個效果還是非常不錯的。
因此,如果是在一個更新頻率非常低而只讀查詢頻率非常高的場景下,打開QC還是比較有優勢的,其他場景下,則不建議使用。而且,QC一般也維持在100MB以內就夠了,沒必要設置超過數百MB。
QC嚴格要求2次SQL請求要完全一樣,包括SQL語句,連接的數據庫、協議版本、字符集等因素都會影響,下面幾個例子中的SQL會被認爲是完全不一樣而不會使用同一個QC內存塊:
mysql> set names latin1; SELECT * FROM table_name; mysql> set names latin1; select * from table_name; mysql> set names utf8; select * from table_name;
此外,QC也不適用於下面幾個場景:
1、子查詢或者外層查詢; 2、存儲過程、存儲函數、觸發器、event中調用的SQL,或者引用到這些結果的; 3、包含一些特殊函數時,例如:BENCHMARK()、CURDATE()、CURRENT_TIMESTAMP()、NOW()、RAND()、UUID()等等; 4、讀取mysql、INFORMATION_SCHEMA、performance_schema 庫數據的; 5、類似SELECT…LOCK IN SHARE MODE、SELECT…FOR UPDATE、SELECT..INTO OUTFILE/DUMPFILE、SELECT..WHRE…IS NULL等語句; 6、SELECT執行計劃用到臨時表(TEMPORARY TABLE); 7、未引用任何表的查詢,例如 SELECT 1+1 這種; 8、產生了 warnings 的查詢; 9、SELECT語句里加了 SQL_NO_CACHE 關鍵字;
更加奇葩的是,MySQL在從QC中取回結果前,會先判斷執行SQL的用戶是否有全部庫、表的SELECT權限,如果沒有,則也不會使用QC。
相比下面這個,其實上面所說的都不重要。
最爲重要的是,在MySQL裏QC是由一個全局鎖在控制,每次更新QC的內存塊都需要進行鎖定。
例如,一次查詢結果是20KB,當前 query_cache_min_res_unit 值設置爲
4KB(默認值就是4KB,可調整),那麼麼本次查詢結果共需要分爲5次寫入QC,每次都要鎖定,可見其成本有多高。
我們可以通過 PROFILING 功能來查看 QC 相關的一些鎖競爭,例如像下面這樣的:
• Waiting for query cache lock • Waiting on query cache mutex
或者,也可以通過執行 SHOW PROCESSLIST 來看線程的狀態,例如:
• checking privileges on cached query 檢查用戶是否有權限讀取QC中的結果集 • checking query cache for query 檢查本次查詢結果是否已經存儲在QC中 • invalidating query cache entries 由於相關表數據已經修改了,因此將QC中的內存記錄被標記爲失效 • sending cached result to client 從QC中,將緩存後的結果返回給客戶程序 • storing result in query cache 將查詢結果緩存到QC中
如果可以頻繁看到上述幾種狀態,那麼說明當前QC基本存在比較重的競爭。
說了這麼多廢話,其實核心要點就一個:
如果線上環境中99%以上都是隻讀,很少有更新,再考慮開啓QC吧,否則,就別開了。
關閉方法很簡單,有兩種:
1、同時設置選項 query_cache_type = 0 和 query_cache_size = 0; 2、如果用源碼編譯MySQL的話,編譯時增加參數 --without-query-cache 即可;