從 MySQL 4.0.1 開始,，MySQL server 有一個(gè)重要的特征：Query Cache,。 當(dāng)在使用中，查詢緩存會存儲一個(gè) SELECT 查詢的文本與被傳送到客戶端的相應(yīng)結(jié)果,。如果之后接收到一個(gè)同樣的查詢,，服務(wù)器將從查詢緩存中檢索結(jié)果，而不是再次分析和執(zhí)行這個(gè)同樣的查詢,。

　　注意：查詢緩存絕不返回過期數(shù)據(jù),。當(dāng)數(shù)據(jù)被修改后，在查詢緩存中的任何相關(guān)詞條均被轉(zhuǎn)儲清除,。

　　在某些表并不經(jīng)常更改,，而你又對它執(zhí)行大量的相同查詢時(shí)，查詢緩存將是非常有用的,。對于許多 WEB 服務(wù)器使用大量的動態(tài)信息,，這是一個(gè)很典型的情況,。

　　下面是查詢緩存的一個(gè)性能數(shù)據(jù)。(這些結(jié)果的產(chǎn)生,，是通過在一個(gè) a Linux Alpha 2 x 500 MHz,、2GB RAM 和 64MB 查詢緩存上執(zhí)行 MySQL 基準(zhǔn)套件和到的)：

　　如果你執(zhí)行的所有查詢均是簡單的(比如從表中一行一行的選取);但是仍然是不同的，所以該查詢不能被緩沖,，查詢緩存處于活動時(shí),，開銷為 13%。這可以被看作是最差的情況,。然而,，在實(shí)際情況下，查詢是比我們的簡單示例要復(fù)雜得多的,，所以開銷通常顯著得低,。

　　在只有一行記錄表中搜索一行后，搜索將快 238% ,。這可以被認(rèn)為是接近于對一個(gè)被緩沖的查詢所期望的最小的加速,。

　　如果你希望禁用查詢緩存，設(shè)置 query_cache_size=0,。禁用了查詢緩存,，將沒有明顯的開銷。(在配置選項(xiàng) --without-query-cache 的幫助下,，查詢緩存可以被排除在外碼之外)

　　 查詢緩存如何運(yùn)作

　　查詢在分析之前先被比較,，因而

　　SELECT * FROM tbl_name

　　和

　　Select * from tbl_name

　　對于查詢緩存被當(dāng)作是不同的查詢，因而查詢需要嚴(yán)格的一致(字節(jié)對字節(jié)的),，才會被認(rèn)為是同樣的,。 另外，如果一個(gè)客戶端使用一個(gè)新的連接協(xié)議格式或不同于其它客戶端的另一個(gè)字符集,，一個(gè)查詢將被視為不同的,。

　　使用不同數(shù)據(jù)庫的，使用不同協(xié)議版本的,，或使用不同的缺省字符串的查詢將被認(rèn)為是不同的查詢,，并將分別的緩沖。

　　高速緩沖不對 SELECT CALC_ROWS ... 和 SELECT FOUND_ROWS() ... 類型的查詢起作用,，因?yàn)檎业降男械臄?shù)目也是被存儲在緩沖里的,。

　　如果查詢結(jié)果被從查詢緩存中返回，那么狀態(tài)變量 Com_select 將不會被增加,，但是 Qcache_hits 卻會增加,。

　　如果一個(gè)表發(fā)生的改變 (INSERT, UPDATE, DELETE, TRUNCATE, ALTER 或 DROP TABLE|DATABASE)，那么所有這張表使用的緩沖的查詢(可能通過一個(gè) MRG_MyISAM 表!)將被得失效，并從緩沖中移除,。

　　InnoDB 表的事務(wù)所做的更改將在一個(gè) COMMIT 被完成時(shí)，使數(shù)據(jù)失效,。

　　如果一個(gè)查詢包括下面的函數(shù),，它將不能被緩沖： 函數(shù) 函數(shù) 函數(shù)

　　User-Defined Functions CONNECTION_ID FOUND_ROWS

　　GET_LOCK RELEASE_LOCK LOAD_FILE

　　MASTER_POS_WAIT NOW SYSDATE

　　CURRENT_TIMESTAMP CURDATE CURRENT_DATE

　　CURTIME CURRENT_TIME DATABASE

　　ENCRYPT (只有一個(gè)參數(shù)調(diào)用) LAST_INSERT_ID RAND

　　UNIX_TIMESTAMP (無參數(shù)調(diào)用) USER BENCHMARK

　　如果一個(gè)查詢包含用戶變量，引用 MySQL 系統(tǒng)數(shù)據(jù)庫,，或下列之一的格式,，SELECT ... IN SHARE MODE, SELECT ... INTO OUTFILE ..., SELECT ... INTO DUMPFILE ... 或 SELECT * FROM AUTOINCREMENT_FIELD IS NULL (檢索最后一個(gè)插入 ID - ODBC 語句)，該查詢亦不可以被緩存,。

　　然而,，F(xiàn)OUND ROWS() 將返回正確的值，即使先前的查詢是從緩存中讀取的,。

　　萬一一個(gè)查詢不使用任何表,，或使用臨時(shí)表，或用戶對任何相關(guān)表有一個(gè)列權(quán)限,，那么查詢將不會被緩存,。

　　在一個(gè)查詢從查詢緩存中讀取前，MySQL 將檢查用戶對所有相關(guān)的數(shù)據(jù)庫和表有 SELECT 權(quán)限,。如果不是這種情況,，緩存的結(jié)果將不能被使用。

　　查詢緩存設(shè)置

　　查詢緩存為了 mysqld 添加了幾個(gè) MySQL 系統(tǒng)變量,，它可以在配置文件中被設(shè)置,，或在啟動 mysqld 時(shí)的命令行上設(shè)置。

　　query_cache_limit 不緩存大于這個(gè)值的結(jié)果,。(缺省為 1M)

　　query_cache_min_res_unit 這個(gè)變量從 4.1 被引進(jìn),。 查詢的結(jié)果 (已被傳送到客戶端的數(shù)據(jù)) 在結(jié)果檢索期間被存儲到查詢緩存中。因而,，數(shù)據(jù)不會以一個(gè)大塊地處理,。查詢緩存在需要時(shí)分配塊用于處理這個(gè)數(shù)據(jù)，所以當(dāng)一個(gè)塊被填充后,，一個(gè)新的塊被分配,。甚為內(nèi)存分配操作是昂貴的，查詢緩存以最小的尺寸 query_cache_min_res_unit 分配塊,。當(dāng)一個(gè)查詢執(zhí)行完成,，最后的結(jié)果塊被修整到實(shí)際數(shù)據(jù)的尺寸大小，以便未使用的內(nèi)存被釋放,。

　　query_cache_min_res_unit 的缺省值為 4 KB,，在大多數(shù)據(jù)情況下已夠用了。

　　如果你有許多查詢返回一個(gè)較小的結(jié)果，缺省的塊尺寸可能會引起內(nèi)存碎片 (顯示為一個(gè)很大數(shù)量的空閑塊(Qcache_free_blocks),，這將引起查詢緩存不得不因缺乏內(nèi)存(Qcache_lowmem_prunes)而從緩存中刪除查詢),。在這種情況下，你應(yīng)該減少 query_cache_min_res_unit,。

　　如果你的主要查詢返回的是大的結(jié)果集(查看 Qcache_total_blocks 和 Qcache_queries_in_cache),，你可以通過增加 query_cache_min_res_unit 來增加性能。然而,，要小心不要將它設(shè)得太大,。

　　query_cache_size 為了存儲老的查詢結(jié)果而分配的內(nèi)存數(shù)量 (以字節(jié)指定) 。如果設(shè)置它為 0 ,，查詢緩沖將被禁止(缺省值為 0 ),。

　　query_cache_type 這個(gè)可以被設(shè)置為 (只能是數(shù)字) 選項(xiàng) 含義

　　0 (OFF, 不緩存或重新得到結(jié)果)

　　1 (ON, 緩存所有的結(jié)果，除了 SELECT SQL_NO_CACHE ... 查詢)

　　2 (DEMAND, 僅緩存 SELECT SQL_CACHE ... 查詢)

　　在一個(gè)線程(連接)內(nèi),，查詢緩存的行為可以被改變,。句法如下所示：

　　QUERY_CACHE_TYPE = OFF | ON | DEMAND QUERY_CACHE_TYPE = 0 | 1 | 2

　　在 SELECT 中的查詢緩存選項(xiàng)

　　有兩個(gè)可能的查詢緩存相關(guān)的參數(shù)可以在一個(gè) SELECT 查詢中被指定：

　　查詢緩存的狀態(tài)和維護(hù)

　　使用 FLUSH QUERY CACHE 命令,，你可以整理查詢緩存，以更好的利用它的內(nèi)存,。這個(gè)命令不會從緩存中移除任何查詢,。FLUSH TABLES 會轉(zhuǎn)儲清除查詢緩存。

　　RESET QUERY CACHE 使命從查詢緩存中移除所有的查詢結(jié)果,。

　　你可以檢查查詢緩存在你的 MySQL 是否被引進(jìn)：

　　mysql> SHOW VARIABLES LIKE 'have_query_cache';

　　+------------------+-------+

　　| Variable_name | Value |

　　+------------------+-------+

　　| have_query_cache | YES |

　　+------------------+-------+

　　1 row in set (0.00 sec)

　　在 SHOW STATUS 中,，你可以監(jiān)視查詢緩存的性能：

　　Total number of queries = Qcache_inserts + Qcache_hits + Qcache_not_cached.

　　查詢緩存使用變長的塊,，因而 Qcache_total_blocks 和 Qcache_free_blocks 可能顯示查詢緩存的碎片,。在 FLUSH QUERY CACHE 之后，只有剩余一個(gè)單獨(dú)的(大的)空閑塊,。

　　注意：每個(gè)查詢最小需要兩個(gè)塊(一個(gè)用于存儲查詢文本,，另一個(gè)或多個(gè)用于存儲查詢結(jié)果)。同樣的,，每個(gè)被一個(gè)查詢使用的表需要一個(gè)塊,，但是，如果有兩個(gè)或更多的查詢使用同一張表,，僅僅只需要分配一個(gè)塊就行了,。

　　你可以使用狀態(tài)變量 Qcache_lowmem_prunes 來諧調(diào)查詢緩存尺寸。它計(jì)數(shù)被從緩存中移除的查詢,，該查詢的移除是為了釋放內(nèi)存,，以緩存新建的查詢,。查詢緩存使用一個(gè) least recently used (LRU) 策略來判斷從緩存中移除哪個(gè)查詢。