mysql Query Cache 默認(rèn)為打開。從某種程度可以提高查詢的效果，但是未必是最優(yōu)的解決方案，如果有的大量的修改和查詢時(shí)，由于修改造成的cache失效，會(huì)給服務(wù)器造成很大的開銷，可以通過query_cache_type【0(OFF)1(ON)2(DEMAND)】來控制緩存的開關(guān).

需要注意的是mysql query cache 是對(duì)大小寫敏感的，因?yàn)镼uery Cache 在內(nèi)存中是以 HASH 結(jié)構(gòu)來進(jìn)行映射，HASH 算法基礎(chǔ)就是組成 SQL 語句的字符，所以 任何sql語句的改變重新cache,這也是項(xiàng)目開發(fā)中要建立sql語句書寫規(guī)范的原因吧

1. 何時(shí)cache

a) mysql query cache內(nèi)容為 select 的結(jié)果集, cache 使用完整的 sql 字符串做 key, 并區(qū)分大小寫，空格等。即兩個(gè)sql必須完全一致才會(huì)導(dǎo)致cache命中。

b) prepared statement永遠(yuǎn)不會(huì)cache到結(jié)果，即使參數(shù)完全一樣。據(jù)說在 5.1 之后會(huì)得到改善。

c) where條件中如包含了某些函數(shù)永遠(yuǎn)不會(huì)被cache, 比如current_date, now等。

d) date 之類的函數(shù)如果返回是以小時(shí)或天級(jí)別的，最好先算出來再傳進(jìn)去。
select * from foo where date1=current_date -- 不會(huì)被 cache
select * from foo where date1='2008-12-30' -- 被cache, 正確的做法

e) 太大的result set不會(huì)被cache (< query_cache_limit)

2. 何時(shí)invalidate

a) 一旦表數(shù)據(jù)進(jìn)行任何一行的修改，基于該表相關(guān)cache立即全部失效。

b) 為什么不做聰明一點(diǎn)判斷修改的是否cache的內(nèi)容？因?yàn)榉治鯿ache內(nèi)容太復(fù)雜，服務(wù)器需要追求最大的性能。

3. 性能

a) cache 未必所有場合總是會(huì)改善性能

當(dāng)有大量的查詢和大量的修改時(shí)，cache機(jī)制可能會(huì)造成性能下降。因?yàn)槊看涡薷臅?huì)導(dǎo)致系統(tǒng)去做cache失效操作，造成不小開銷。

另外系統(tǒng)cache的訪問由一個(gè)單一的全局鎖來控制，這時(shí)候大量>的查詢將被阻塞，直至鎖釋放。所以不要簡單認(rèn)為設(shè)置cache必定會(huì)帶來性能提升。

b) 大result set不會(huì)被cache的開銷

太大的result set不會(huì)被cache, 但mysql預(yù)先不知道result set的長度，所以只能等到reset set在cache添加到臨界值 query_cache_limit 之后才會(huì)簡單的把這個(gè)cache 丟棄。這并不是一個(gè)高效的操作。如果mysql status中Qcache_not_cached太大的話, 則可對(duì)潛在的大結(jié)果集的sql顯式添加 SQL_NO_CACHE 的控制。
query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache

4. 內(nèi)存池使用

mysql query cache 使用內(nèi)存池技術(shù)，自己管理內(nèi)存釋放和分配，而不是通過操作系統(tǒng)。內(nèi)存池使用的基本單位是變長的block, 一個(gè)result set的cache通過鏈表把這些block串起來。因?yàn)榇娣舝esult set的時(shí)候并不知道這個(gè)resultset最終有多大。block最短長度為 query_cache_min_res_unit, resultset 的最后一個(gè)block會(huì)執(zhí)行trim操作。

Query Cache 在提高數(shù)據(jù)庫性能方面具有非常重要的作用。

其設(shè)定也非常簡單，僅需要在配置文件寫入兩行： query_cache_type 和 query_cache _size，而且 MySQL 的 query cache 非?？?！而且一旦命中，就直接發(fā)送給客戶端，節(jié)約大量的 CPU 時(shí)間。 

當(dāng)然，非 SELECT 語句對(duì)緩沖是有影響的，它們可能使緩沖中的數(shù)據(jù)過期。一個(gè) UPDATE 語句引起的部分表修改，將導(dǎo)致對(duì)該表所有的緩沖數(shù)據(jù)失效，這是 MySQL 為了平衡性能而沒有采取的措施。因?yàn)?，如果每?UPDATE 需要檢查修改的數(shù)據(jù)，然后撤出部分緩沖將導(dǎo)致代碼的復(fù)雜度增加。

query_cache_type 0 代表不使用緩沖， 1 代表使用緩沖，2 代表根據(jù)需要使用。

設(shè)置 1 代表緩沖永遠(yuǎn)有效，如果不需要緩沖，就需要使用如下語句：

代碼如下

SELECT SQL_NO_CACHE * FROM my_table WHERE ...

如果設(shè)置為 2 ，需要開啟緩沖，可以用如下語句：

代碼如下

SELECT SQL_CACHE * FROM my_table WHERE ...

用 SHOW STATUS 可以查看緩沖的情況：

代碼如下

mysql> show status like 'Qca%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 8 |
| Qcache_inserts | 545875 |
| Qcache_hits | 83951 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 2343256 |
| Qcache_free_memory | 33508248 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 18 |
+-------------------------+----------+
8 rows in set (0.00 sec)

如果需要計(jì)算命中率，需要知道服務(wù)器執(zhí)行了多少 SELECT 語句：

代碼如下

mysql> show status like 'Com_sel%';
+---------------+---------+
| Variable_name | Value |
+---------------+---------+
| Com_select | 2889628 |
+---------------+---------+
1 row in set (0.01 sec)

在本例中， MySQL 命中了 2,889,628 條查詢中的 83,951 條，而且 INSERT 語句只有 545,875 條。因此，它們兩者的和和280萬的總查詢相比有很大差距，因此，我們知道本例使用的緩沖類型是 2 。

而在類型是 1 的例子中， Qcache_hits 的數(shù)值會(huì)遠(yuǎn)遠(yuǎn)大于 Com_select

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論