從 MySQL
開始
MySQL server 有一個重要的特征
Query Cache
當在使用中
查詢緩存會存儲一個 SELECT 查詢的文本與被傳送到客戶端的相應結果
如果之後接收到一個同樣的查詢
服務器將從查詢緩存中檢索結果
而不是再次分析和執行這個同樣的查詢
注意
查詢緩存絕不返回過期數據
當數據被修改後
在查詢緩存中的任何相關詞條均被轉儲清除
在某些表並不經常更改
而你又對它執行大量的相同查詢時
查詢緩存將是非常有用的
對於許多 WEB 服務器使用大量的動態信息
這是一個很典型的情況
下面是查詢緩存的一個性能數據
（這些結果的產生
是通過在一個 a Linux Alpha
x
MHz
GB RAM 和
MB 查詢緩存上執行 MySQL 基准套件和到的）
如果你執行的所有查詢均是簡單的（比如從表中一行一行的選取）
但是仍然是不同的
所以該查詢不能被緩沖
查詢緩存處於活動時
開銷為
%
這可以被看作是最差的情況
然而
在實際情況下
查詢是比我們的簡單示例要復雜得多的
所以開銷通常顯著得低
在只有一行記錄表中搜索一行後
搜索將快
%
這可以被認為是接近於對一個被緩沖的查詢所期望的最小的加速
如果你希望禁用查詢緩存
設置 query_cache_size=
禁用了查詢緩存
將沒有明顯的開銷
（在配置選項
without
query
cache 的幫助下
查詢緩存可以被排除在外碼之外）
查詢緩存如何運作
查詢在分析之前先被比較
因而
SELECT * FROM tbl_name
和
Select * from tbl_name
對於查詢緩存被當作是不同的查詢
因而查詢需要嚴格的一致（字節對字節的）
才會被認為是同樣的
另外
如果一個客戶端使用一個新的連接協議格式或不同於其它客戶端的另一個字符集
一個查詢將被視為不同的
使用不同數據庫的
使用不同協議版本的
或使用不同的缺省字符串的查詢將被認為是不同的查詢
並將分別的緩沖
高速緩沖不對 SELECT CALC_ROWS … 和 SELECT FOUND_ROWS（） … 類型的查詢起作用
因為找到的行的數目也是被存儲在緩沖裡的
如果查詢結果被從查詢緩存中返回
那麼狀態變量 Com_select 將不會被增加
但是 Qcache_hits 卻會增加
查看章節
查詢緩存的狀態和維護
如果一個表發生的改變 （INSERT
UPDATE
DELETE
TRUNCATE
ALTER 或 DROP TABLE|DATABASE）
那麼所有這張表使用的緩沖的查詢（可能通過一個 MRG_MyISAM 表！）將被得失效
並從緩沖中移除
InnoDB 表的事務所做的更改將在一個 COMMIT 被完成時
使數據失效
如果一個查詢包括下面的函數
它將不能被緩沖
函數 函數 函數
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 （只有一個參數調用） LAST_INSERT_ID RAND
UNIX_TIMESTAMP （無參數調用） USER BENCHMARK
如果一個查詢包含用戶變量
引用 MySQL 系統數據庫
或下列之一的格式
SELECT … IN SHARE MODE
SELECT … INTO OUTFILE …
SELECT … INTO DUMPFILE … 或 SELECT * FROM AUTOINCREMENT_FIELD IS NULL （檢索最後一個插入 ID
ODBC 語句）
該查詢亦不可以被緩存
然而
FOUND ROWS（） 將返回正確的值
即使先前的查詢是從緩存中讀取的
萬一一個查詢不使用任何表
或使用臨時表
或用戶對任何相關表有一個列權限
那麼查詢將不會被緩存
在一個查詢從查詢緩存中讀取前
MySQL 將檢查用戶對所有相關的數據庫和表有 SELECT 權限
如果不是這種情況
緩存的結果將不能被使用
查詢緩存設置
查詢緩存為了 mysqld 添加了幾個 MySQL 系統變量
它可以在配置文件中被設置
或在啟動 mysqld 時的命令行上設置
query_cache_limit 不緩存大於這個值的結果
（缺省為
M）
query_cache_min_res_unit 這個變量從
被引進
查詢的結果 （已被傳送到客戶端的數據） 在結果檢索期間被存儲到查詢緩存中
因而
數據不會以一個大塊地處理
查詢緩存在需要時分配塊用於處理這個數據
所以當一個塊被填充後
一個新的塊被分配
甚為內存分配操作是昂貴的
查詢緩存以最小的尺寸 query_cache_min_res_unit 分配塊
當一個查詢執行完成
最後的結果塊被修整到實際數據的尺寸大小
以便未使用的內存被釋放
query_cache_min_res_unit 的缺省值為
KB
在大多數據情況下已夠用了
如果你有許多查詢返回一個較小的結果
缺省的塊尺寸可能會引起內存碎片 （顯示為一個很大數量的空閒塊（Qcache_free_blocks）
這將引起查詢緩存不得不因缺乏內存（Qcache_lowmem_prunes）而從緩存中刪除查詢）
在這種情況下
你應該減少 query_cache_min_res_unit
如果你的主要查詢返回的是大的結果集（查看 Qcache_total_blocks 和 Qcache_queries_in_cache）
你可以通過增加 query_cache_min_res_unit 來增加性能
然而
要小心不要將它設得太大
query_cache_size 為了存儲老的查詢結果而分配的內存數量 （以字節指定）
如果設置它為
查詢緩沖將被禁止（缺省值為
）
query_cache_type 這個可以被設置為 （只能是數字） 選項 含義
（OFF
不緩存或重新得到結果）
（ON
緩存所有的結果
除了 SELECT SQL_NO_CACHE … 查詢）
（DEMAND
僅緩存 SELECT SQL_CACHE … 查詢）
在一個線程（連接）內
查詢緩存的行為可以被改變
句法如下所示
QUERY_CACHE_TYPE = OFF | ON | DEMAND QUERY_CACHE_TYPE =
|
|
選項 含義
or OFF 不緩存或重新得到結果
or ON 緩存所有的結果
除了 SELECT SQL_NO_CACHE … 查詢
or DEMAND 僅緩存 SELECT SQL_CACHE … 查詢
在 SELECT 中的查詢緩存選項
有兩個可能的查詢緩存相關的參數可以在一個 SELECT 查詢中被指定
選項 含義
SQL_CACHE 如果 QUERY_CACHE_TYPE 為 DEMAND
允許該查詢被緩存
如果 QUERY_CACHE_TYPE 為 ON
這是缺省的
如果 QUERY_CACHE_TYPE 為 OFF
它不做任何事
SQL_NO_CACHE 使這個查詢不被緩存
不允許這個查詢被存儲到高速緩存中
查詢緩存的狀態和維護
使用 FLUSH QUERY CACHE 命令
你可以整理查詢緩存
以更好的利用它的內存
這個命令不會從緩存中移除任何查詢
FLUSH TABLES 會轉儲清除查詢緩存
RESET QUERY CACHE 使命從查詢緩存中移除所有的查詢結果
你可以檢查查詢緩存在你的 MySQL 是否被引進
mysql> SHOW VARIABLES LIKE
have_query_cache
;
+
+
+
| Variable_name | Value |
+
+
+
| have_query_cache | YES |
+
+
+
row in set （
sec）
在 SHOW STATUS 中
你可以監視查詢緩存的性能
變量 含義
Qcache_queries_in_cache 在緩存中已注冊的查詢數目
Qcache_inserts 被加入到緩存中的查詢數目
Qcache_hits 緩存采樣數數目
Qcache_lowmem_prunes 因為缺少內存而被從緩存中刪除的查詢數目
Qcache_not_cached 沒有被緩存的查詢數目 （不能被緩存的
或由於 QUERY_CACHE_TYPE）
Qcache_free_memory 查詢緩存的空閒內存總數
Qcache_free_blocks 查詢緩存中的空閒內存塊的數目
Qcache_total_blocks 查詢緩存中的塊的總數目
Total number of queries = Qcache_inserts + Qcache_hits + Qcache_not_cached
查詢緩存使用變長的塊
因而 Qcache_total_blocks 和 Qcache_free_blocks 可能顯示查詢緩存的碎片
在 FLUSH QUERY CACHE 之後
只有剩余一個單獨的（大的）空閒塊
注意
每個查詢最小需要兩個塊（一個用於存儲查詢文本
另一個或多個用於存儲查詢結果）
同樣的
每個被一個查詢使用的表需要一個塊
但是
如果有兩個或更多的查詢使用同一張表
僅僅只需要分配一個塊就行了
你可以使用狀態變量 Qcache_lowmem_prunes 來諧調查詢緩存尺寸
它計數被從緩存中移除的查詢
該查詢的移除是為了釋放內存
以緩存新建的查詢
查詢緩存使用一個 least recently used （LRU） 策略來判斷從緩存中移除哪個查詢
From:http://tw.wingwit.com/Article/program/MySQL/201311/29499.html
