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

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

1. 何時cache

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

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

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

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

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

2. 何時invalidate

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

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

3. 性能

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

當有大量的查詢和大量的修改時，cache機制可能會造成性能下降。因為每次修改會導(dǎo)致系統(tǒng)去做cache失效操作，造成不小開銷。

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

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

太大的result set不會被cache, 但mysql預(yù)先不知道result set的長度，所以只能等到reset set在cache添加到臨界值 query_cache_limit 之后才會簡單的把這個cache 丟棄。這并不是一個高效的操作。如果mysql status中Qcache_not_cached太大的話, 則可對潛在的大結(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, 一個result set的cache通過鏈表把這些block串起來。因為存放result set的時候并不知道這個resultset最終有多大。block最短長度為 query_cache_min_res_unit, resultset 的最后一個block會執(zhí)行trim操作。

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

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

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

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

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

代碼如下

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)

如果需要計算命中率，需要知道服務(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ù)值會遠遠大于 Com_select

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