顧名思義，MySQL Query Cache就是用來緩存和Query相關的數(shù)據(jù)的。具體來說，Query Cache 緩存了我們客戶端提交給 MySQL 的 SELECT 語句以及該語句的結(jié)果集。大概來講，就是將 SELECT 語句和語句的結(jié)果做了一個HASH 映射關系然后保存在一定的內(nèi)存區(qū)域中。

在大部分的MySQL分發(fā)版本中，Query Cache 功能默認都是打開的，我們可以通過調(diào)整 MySQL Server 的參數(shù)選項打開該功能。主要由以下5個參數(shù)構(gòu)成：

◆query_cache_limit：允許 Cache 的單條 Query 結(jié)果集的最大容量，默認是1MB，超過此參數(shù)設置的 Query 結(jié)果集將不會被 Cache
◆query_cache_min_res_unit：設置 Query Cache 中每次分配內(nèi)存的最小空間大小，也就是每個 Query 的 Cache 最小占用的內(nèi)存空間大小
◆query_cache_size：設置 Query Cache 所使用的內(nèi)存大小，默認值為0，大小必須是1024的整數(shù)倍，如果不是整數(shù)倍，MySQL 會自動調(diào)整降低最小量以達到1024的倍數(shù)
◆query_cache_type：控制 Query Cache 功能的開關，可以設置為0(OFF),1(ON)和2(DEMAND)三種，意義分別如下：

0(OFF)：關閉 Query Cache 功能，任何情況下都不會使用 Query Cache
1(ON)：開啟 Query Cache 功能，但是當 SELECT 語句中使用的 SQL_NO_CACHE 提示后，將不使用Query Cache
2(DEMAND)：開啟 Query Cache 功能，但是只有當 SELECT 語句中使用了 SQL_CACHE 提示后，才使用 Query Cache
query_cache_wlock_invalidate：控制當有寫鎖定發(fā)生在表上的時刻是否先失效該表相關的 Query Cache，如果設置為 1(TRUE)，則在寫鎖定的同時將失效該表相關的所有 Query Cache，如果設置為0(FALSE)則在鎖定時刻仍然允許讀取該表相關的 Query Cache。

Query Cache 如何處理子查詢的？

這是我遇到的最為常見的一個問題。其實 Query Cache 是以客戶端請求提交的 Query 為對象來處理的，只要客戶端請求的是一個 Query，無論這個 Query 是一個簡單的單表查詢還是多表 Join，亦或者是帶有子查詢的復雜 SQL，都被當作成一個 Query，不會被分拆成多個 Query 來進行 Cache。所以，存在子查詢的復雜 Query 也只會產(chǎn)生一個Cache對象，子查詢不會產(chǎn)生單獨的Cache內(nèi)容。UNION[ALL] 類型的語句也同樣如此。

Query Cache 是以 block 的方式存儲的數(shù)據(jù)塊嗎？

不是，Query Cache 中緩存的內(nèi)容僅僅只包含該 Query 所需要的結(jié)果數(shù)據(jù)，是結(jié)果集。當然，并不僅僅只是結(jié)果數(shù)據(jù)，還包含與該結(jié)果相關的其他信息，比如產(chǎn)生該 Cache 的客戶端連接的字符集，數(shù)據(jù)的字符集，客戶端連接的 Default Database等。

Query Cache 為什么效率會非常高，即使所有數(shù)據(jù)都可以 Cache 進內(nèi)存的情況下，有些時候也不如使用 Query Cache 的效率高？

Query Cache 的查找，是在 MySQL 接受到客戶端請求后在對 Query 進行權(quán)限驗證之后，SQL 解析之前。也就是說，當 MySQL 接受到客戶端的SQL后，僅僅只需要對其進行相應的權(quán)限驗證后就會通過 Query Cache 來查找結(jié)果，甚至都不需要經(jīng)過 Optimizer 模塊進行執(zhí)行計劃的分析優(yōu)化，更不許要發(fā)生任何存儲引擎的交互，減少了大量的磁盤 IO 和 CPU 運算，所以效率非常高。

客戶端提交的 SQL 語句大小寫對 Query Cache 有影響嗎？

有，由于 Query Cache 在內(nèi)存中是以 HASH 結(jié)構(gòu)來進行映射，HASH 算法基礎就是組成 SQL 語句的字符，所以必須要整個 SQL 語句在字符級別完全一致，才能在 Query Cache 中命中，即使多一個空格也不行。

一個 SQL 語句在 Query Cache 中的內(nèi)容，在什么情況下會失效？

為了保證 Query Cache 中的內(nèi)容與是實際數(shù)據(jù)絕對一致，當表中的數(shù)據(jù)有任何變化，包括新增，修改，刪除等，都會使所有引用到該表的 SQL 的 Query Cache 失效。

為什么我的系統(tǒng)在開啟了 Query Cache 之后整體性能反而下降了？

當開啟了 Query Cache 之后，尤其是當我們的 query_cache_type 參數(shù)設置為 1 以后，MySQL 會對每個 SELECT 語句都進行 Query Cache 查找，查找操作雖然比較簡單，但仍然也是要消耗一些 CPU 運算資源的。而由于 Query Cache 的失效機制的特性，可能由于表上的數(shù)據(jù)變化比較頻繁，大量的 Query Cache 頻繁的被失效，所以 Query Cache 的命中率就可能比較低下。所以有些場景下，Query Cache 不僅不能提高效率，反而可能造成負面影響。

如何確認一個系統(tǒng)的 Query Cache 的運行是否健康，命中率如何，設置量是否足夠？

MySQL 提供了一系列的 Global Status 來記錄 Query Cache 的當前狀態(tài)，具體如下：

◆Qcache_free_blocks：目前還處于空閑狀態(tài)的 Query Cache 中內(nèi)存 Block 數(shù)目
◆Qcache_free_memory：目前還處于空閑狀態(tài)的 Query Cache 內(nèi)存總量
◆Qcache_hits：Query Cache 命中次數(shù)
◆Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次數(shù)，也就是沒有命中的次數(shù)
◆Qcache_lowmem_prunes：當 Query Cache 內(nèi)存容量不夠，需要從中刪除老的 Query Cache 以給新的 Cache 對象使用的次數(shù)
◆Qcache_not_cached：沒有被 Cache 的 SQL 數(shù)，包括無法被 Cache 的 SQL 以及由于 query_cache_type 設置的不會被 Cache 的 SQL
◆Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 數(shù)量
◆Qcache_total_blocks：Query Cache 中總的 Block 數(shù)量

可以根據(jù)這幾個狀態(tài)計算出 Cache 命中率，計算出 Query Cache 大小設置是否足夠，總的來說，我個人不建議將 Query Cache 的大小設置超過256MB，這也是業(yè)界比較常用的做法。

MySQL Cluster 是否可以使用 Query Cache？

其實在我們的生產(chǎn)環(huán)境中也沒有使用 MySQL Cluster，所以我也沒有在 MySQL Cluster 環(huán)境中使用 Query Cache 的實際經(jīng)驗，只是 MySQL 文檔中說明確實可以在 MySQL Cluster 中使用 Query Cache。從 MySQL Cluster 的原理來分析，也覺得應該可以使用，畢竟 SQL 節(jié)點和數(shù)據(jù)節(jié)點比較獨立，各司其職，只是 Cache 的失效機制會要稍微復雜一點。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com