MYSQL的Query Cache
當你的數據庫打開了Query Cache（簡稱QC）功能後，數據庫在執行SELECT語句時，會將其結果放到QC中，當下一次處理同樣的SELECT請求時，數據庫就會從QC取得結果，而不需要去數據表中查詢。
在這個“Cache爲王”的時代，我們總是通過不同的方式去緩存我們的結果從而提高響應效率，但一個緩存機制是否有效，效果如何，卻是一個需要好好思考的問題。在MySQL中的Query Cache就是一個適用較少情況的緩存機制。在上圖中，如果緩存命中率非常高的話，有測試表明在極端情況下可以提高效率238%[1]。但實際情況如何？Query Cache有如下規則，如果數據表被更改，那麼和這個數據表相關的全部Cache全部都會無效，並刪除之。這裏“數據表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。舉個例子，如果數據表posts訪問頻繁，那麼意味着它的很多數據會被QC緩存起來，但是每一次posts數據表的更新，無論更新是不是影響到了cache的數據，都會將全部和posts表相關的cache清除。如果你的數據表更新頻繁的話，那麼Query Cache將會成爲系統的負擔。有實驗表明，糟糕時，QC會降低系統13%[1]的處理能力。
如果你的應用對數據庫的更新很少，那麼QC將會作用顯著。比較典型的如博客系統，一般博客更新相對較慢，數據表相對穩定不變，這時候QC的作用會比較明顯。
再如，一個更新頻繁的BBS系統。下面是一個實際運行的論壇數據庫的狀態參數：
| QCache_hit | 5280438 |
| QCache_insert | 8008948 |
| Qcache_not_cache | 95372 |
| Com select | 8104159 |
可以看到，數據庫一共往QC中寫入了約800W次緩存，但是實際命中的只有約500W次。也就是說，每一個緩存的使用率約爲0.66次。很難說，該緩存的作用是否大於QC系統所帶來的開銷。但是有一點是很肯定的，QC緩存的作用是很微小的，如果應用層能夠實現緩存，將可以忽略QC的效果。
————-下面是關於QC的一些其他細節—————–
一、Query Cache相關參數：
- query_cache_size QC佔用空間大小，通過將其設置爲0關閉QC功能
- query_cache_type 0表示關閉QC；1表示正常緩存；2表示SQL_CACHE才緩存
- query_cache_limit 最大緩存結果集
- query_cache_min_res_unit 手冊上說，QC會按照這個值分配緩存block的大小。
- Qcache_lowmem_prunes 這是一個狀態變量(show status)，當緩存空間不夠需要釋放舊的緩存時，該值會自增。
二、Query Cache觀察：
CREATE TABLE t1(id INT,var1 varchar(10));
//Com_select:8 Qcache_hits:1
INSERT INTO t1 VALUES(1,’WWW’);
//Com_select:8 Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
//Com_select:9 Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
//Com_select:9 Qcache_hits:2 Qcache_queries_in_cache:1
INSERT INTO t1 VALUES(2,’RRRR’);
//Com_select:9 Qcache_hits:2 Qcache_queries_in_cache:0
SELECT * FROM t1 WHERE id=1; //INSERT後Cache失效
//Com_select:10 Qcache_hits:2 Qcache_queries_in_cache:1參考：
- http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
- http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
- http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/