終于看了一直景仰的 High Performance MySQL Second Edition 一書，看了一些章節(jié)并把其中一些觀點(diǎn)記錄了下來，本文是整理 chapter 5. Advance MySQL features 部分觀點(diǎn)所得。

1. 何時cache
a) mysql query cache內(nèi)容為 select 的結(jié)果集, cache 使用完整的 sql 字符串做 key, 并區(qū)分大小寫，空格等。即兩個sql必須完全一致才會導(dǎo)致cache命中。
b) prepared statement永遠(yuǎn)不會cache到結(jié)果，即使參數(shù)完全一樣。據(jù)說在 5.1 之后會得到改善。
c) where條件中如包含了某些函數(shù)永遠(yuǎn)不會被cache, 比如current_date, now等。
d) date 之類的函數(shù)如果返回是以小時或天級別的，最好先算出來再傳進(jìn)去。
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ù)進(jìn)行任何一行的修改，基于該表相關(guān)cache立即全部失效。
b) 為什么不做聰明一點(diǎn)判斷修改的是否cache的內(nèi)容？因?yàn)榉治鯿ache內(nèi)容太復(fù)雜，服務(wù)器需要追求最大的性能。

3. 性能
a) cache 未必所有場合總是會改善性能
當(dāng)有大量的查詢和大量的修改時，cache機(jī)制可能會造成性能下降。因?yàn)槊看涡薷臅?dǎo)致系統(tǒng)去做cache失效操作，造成不小開銷。
另外系統(tǒng)cache的訪問由一個單一的全局鎖來控制，這時候大量>的查詢將被阻塞，直至鎖釋放。所以不要簡單認(rèn)為設(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串起來。因?yàn)榇娣舝esult set的時候并不知道這個resultset最終有多大。block最短長度為 query_cache_min_res_unit, resultset 的最后一個block會執(zhí)行trim操作。
(引用：High Performance MySQL 原書Figure 5-1 插圖)

定長：空間浪費(fèi)
變長：需清理碎片
block 小： 鏈表超長，訪問大塊數(shù)據(jù)效率低。

另外發(fā)現(xiàn) surfchen 的 MySQL的Query Cache 對這方面的內(nèi)容描述也不錯，可以和本文互為補(bǔ)充。