對(duì)mysql查詢緩存從五個(gè)角度進(jìn)行詳細(xì)的分析：Query Cache的工作原理、如何配置、如何維護(hù)、如何判斷查詢緩存的性能、適合的業(yè)務(wù)場(chǎng)景分析。

工作原理

查詢緩存的工作原理，基本上可以概括為：
緩存SELECT操作或預(yù)處理查詢（注釋：5.1.17開始支持）的結(jié)果集和SQL語(yǔ)句；
新的SELECT語(yǔ)句或預(yù)處理查詢語(yǔ)句，先去查詢緩存，判斷是否存在可用的記錄集，判斷標(biāo)準(zhǔn)：與緩存的SQL語(yǔ)句，是否完全一樣，區(qū)分大小寫；

查詢緩存對(duì)什么樣的查詢語(yǔ)句，無(wú)法緩存其記錄集，大致有以下幾類：
查詢語(yǔ)句中加了SQL_NO_CACHE參數(shù)；
查詢語(yǔ)句中含有獲得值的函數(shù)，包涵自定義函數(shù)，如：CURDATE()、GET_LOCK()、RAND()、CONVERT_TZ等；
對(duì)系統(tǒng)數(shù)據(jù)庫(kù)的查詢：mysql、information_schema
查詢語(yǔ)句中使用SESSION級(jí)別變量或存儲(chǔ)過(guò)程中的局部變量；
查詢語(yǔ)句中使用了LOCK  IN SHARE MODE、FOR UPDATE的語(yǔ)句
查詢語(yǔ)句中類似SELECT …INTO 導(dǎo)出數(shù)據(jù)的語(yǔ)句；
事務(wù)隔離級(jí)別為：Serializable情況下，所有查詢語(yǔ)句都不能緩存；
對(duì)臨時(shí)表的查詢操作；
存在警告信息的查詢語(yǔ)句；
不涉及任何表或視圖的查詢語(yǔ)句；
某用戶只有列級(jí)別權(quán)限的查詢語(yǔ)句；

查詢緩存的優(yōu)缺點(diǎn)：

不需要對(duì)SQL語(yǔ)句做任何解析和執(zhí)行，當(dāng)然語(yǔ)法解析必須通過(guò)在先，直接從Query  Cache中獲得查詢結(jié)果；
查詢緩存的判斷規(guī)則，不夠智能，也即提高了查詢緩存的使用門檻，降低其效率；
Query Cache的起用，會(huì)增加檢查和清理Query Cache中記錄集的開銷，而且存在SQL語(yǔ)句緩存的表，每一張表都只有一個(gè)對(duì)應(yīng)的全局鎖；

配置

是否啟用mysql查詢緩存，可以通過(guò)2個(gè)參數(shù)：query_cache_type和query_cache_size，其中任何一個(gè)參數(shù)設(shè)置為0都意味著關(guān)閉查詢緩存功能，但是正確的設(shè)置推薦query_cache_type=0。

query_cache_type
值域?yàn)椋? -– 不啟用查詢緩存；
值域?yàn)椋? -– 啟用查詢緩存，只要符合查詢緩存的要求，客戶端的查詢語(yǔ)句和記錄集斗可以
緩存起來(lái)，共其他客戶端使用；
值域?yàn)椋? -– 啟用查詢緩存，只要查詢語(yǔ)句中添加了參數(shù)：sql_cache，且符合查詢緩存的要求，客戶端的查詢語(yǔ)句和記錄集，則可以緩存起來(lái)，共其他客戶端使用；

query_cache_size
允許設(shè)置query_cache_size的值最小為40K，對(duì)于最大值則可以幾乎認(rèn)為無(wú)限制，實(shí)際生產(chǎn)環(huán)境的應(yīng)用經(jīng)驗(yàn)告訴我們，該值并不是越大， 查詢緩存的命中率就越高，也不是對(duì)服務(wù)器負(fù)載下降貢獻(xiàn)大，反而可能抵消其帶來(lái)的好處，甚至增加服務(wù)器的負(fù)載，至于該如何設(shè)置，下面的章節(jié)講述，推薦設(shè)置 為：64M；

query_cache_limit
限制查詢緩存區(qū)最大能緩存的查詢記錄集，可以避免一個(gè)大的查詢記錄集占去大量的內(nèi)存區(qū)域，而且往往小查詢記錄集是最有效的緩存記錄集，默認(rèn)設(shè)置為1M，建議修改為16k~1024k之間的值域，不過(guò)最重要的是根據(jù)自己應(yīng)用的實(shí)際情況進(jìn)行分析、預(yù)估來(lái)設(shè)置；

query_cache_min_res_unit
設(shè)置查詢緩存分配內(nèi)存的最小單位，要適當(dāng)?shù)卦O(shè)置此參數(shù)，可以做到為減少內(nèi)存塊的申請(qǐng)和分配次數(shù)，但是設(shè)置過(guò)大可能導(dǎo)致內(nèi)存碎片數(shù)值上升。默認(rèn)值為4K，建議設(shè)置為1k~16K

query_cache_wlock_invalidate
該參數(shù)主要涉及MyISAM引擎，若一個(gè)客戶端對(duì)某表加了寫鎖，其他客戶端發(fā)起的查詢請(qǐng)求，且查詢語(yǔ)句有對(duì)應(yīng)的查詢緩存記錄，是否允許直接讀取查詢緩存的記錄集信息，還是等待寫鎖的釋放。默認(rèn)設(shè)置為0，也即允許；

維護(hù)

查詢緩區(qū)的碎片整理

查詢緩存使用一段時(shí)間之后，一般都會(huì)出現(xiàn)內(nèi)存碎片，為此需要監(jiān)控相關(guān)狀態(tài)值，并且定期進(jìn)行內(nèi)存碎片的整理，碎片整理的操作語(yǔ)句：FLUSH QUERY CACHE；

清空查詢緩存的數(shù)據(jù)
那些操作操作可能觸發(fā)查詢緩存，把所有緩存的信息清空，以避免觸發(fā)或需要的時(shí)候，知道如何做，二類可觸發(fā)查詢緩存數(shù)據(jù)全部清空的命令：
(1).RESET QUERY CACHE；
(2).FLUSH TABLES；

性能監(jiān)控

碎片率
查詢緩存內(nèi)存碎片率=Qcache_free_blocks / Qcache_total_blocks * 100%

命中率
查詢緩存命中率=(Qcache_hits – Qcache_inserts) / Qcache_hits * 100%

內(nèi)存使用率
查詢緩存內(nèi)存使用率=(query_cache_size – Qcache_free_memory) / query_cache_size * 100%

Qcache_lowmem_prunes
該參數(shù)值對(duì)于檢測(cè)查詢緩存區(qū)的內(nèi)存大小設(shè)置是否，有非常關(guān)鍵性的作用，其代表的意義為：查詢緩存去因內(nèi)存不足而不得不從查詢緩存區(qū)刪除的查詢緩存信息，刪除算法為L(zhǎng)RU；
query_cache_min_res_unit

內(nèi)存塊分配的最小單元非常重要，設(shè)置過(guò)大可能增加內(nèi)存碎片的概率發(fā)生，太小又可能增加內(nèi)存分配的消耗，為此在系統(tǒng)平穩(wěn)運(yùn)行一個(gè)階段性后，可參考公式的計(jì)算值：
查詢緩存最小內(nèi)存塊 = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache
query_cache_size

我們?nèi)绾闻袛鄎uery_cache_size是否設(shè)置過(guò)小，依然也只有先預(yù)設(shè)置一個(gè)值，推薦為：32M~128M之間的區(qū)域，待系統(tǒng)平穩(wěn)運(yùn)行一個(gè)時(shí)間段（至少1周），并且觀察這周內(nèi)的相關(guān)狀態(tài)值：
(1).Qcache_lowmem_prunes；
(2).命中率；
(3).內(nèi)存使用率；

若整個(gè)平穩(wěn)運(yùn)行期監(jiān)控獲得的信息，為命中率高于80%，內(nèi)存使用率超過(guò)80%，并且Qcache_lowmem_prunes的值不停地增加，而且增加的數(shù)值還較大，則說(shuō)明我們?yōu)椴樵兙彌_區(qū)分配的內(nèi)存過(guò)小，可以適當(dāng)?shù)卦黾硬樵兙彺鎱^(qū)的內(nèi)存大?。?/p>

若是整個(gè)平穩(wěn)運(yùn)行期監(jiān)控獲得的信息，為命中率低于40%，Qcache_lowmem_prunes的值也保持一個(gè)平穩(wěn)狀態(tài)，則說(shuō)明我們的查詢緩沖區(qū)的內(nèi) 存設(shè)置過(guò)大，或者說(shuō)業(yè)務(wù)場(chǎng)景重復(fù)執(zhí)行一樣查詢語(yǔ)句的概率低，同時(shí)若還監(jiān)測(cè)到一定量的freeing items，那么必須考慮把查詢緩存的內(nèi)存條小，甚至關(guān)閉查詢緩存功能；

業(yè)務(wù)場(chǎng)景

通過(guò)上述的知識(shí)梳理和分析，我們至少知道查詢緩存的以下幾點(diǎn)：
查詢緩存能夠加速已經(jīng)存在緩存的查詢語(yǔ)句的速度，可以不用重新解析和執(zhí)行而獲得正確得記錄集；
查詢緩存中涉及的表，每一個(gè)表對(duì)象都有一個(gè)屬于自己的全局性質(zhì)的鎖；
表若是做DDL、FLUSH TABLES 等類似操作，觸發(fā)相關(guān)表的查詢緩存信息清空；
表對(duì)象的DML操作，必須優(yōu)先判斷是否需要清理相關(guān)查詢緩存的記錄信息，將不可避免地出現(xiàn)鎖等待事件；
查詢緩存的內(nèi)存分配問(wèn)題，不可避免地產(chǎn)生一些內(nèi)存碎片；
查詢緩存對(duì)是否是一樣的查詢語(yǔ)句，要求非?？量蹋疫€不智能；

我們?cè)僦匦禄氐奖竟?jié)的重點(diǎn)上，查詢緩存適合什么樣的業(yè)務(wù)場(chǎng)景呢？只要是清楚了查詢緩存的上述優(yōu)缺點(diǎn)，就不難羅列出來(lái)，業(yè)務(wù)場(chǎng)景要求：
整個(gè)系統(tǒng)以讀為主的業(yè)務(wù)，比如門戶型、新聞?lì)悺?bào)表型、論壇等網(wǎng)站；
查詢語(yǔ)句操作的表對(duì)象，非頻繁地進(jìn)行DML操作，可以使用query_cache_type=2模式，然后SQL語(yǔ)句加SQL_CACHE參數(shù)指定；

最新評(píng)論