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

1. 何時(shí)cache
a) mysql query cache內(nèi)容為 select 的結(jié)果集, cache 使用完整的 sql 字符串做 key, 并區(qū)分大小寫，空格等。即兩個(gè)sql必須完全一致才會(huì)導(dǎo)致cache命中。
b) prepared statement永遠(yuǎn)不會(huì)cache到結(jié)果，即使參數(shù)完全一樣。據(jù)說在 5.1 之后會(huì)得到改善。
c) where條件中如包含了某些函數(shù)永遠(yuǎn)不會(huì)被cache, 比如current_date, now等。
d) date 之類的函數(shù)如果返回是以小時(shí)或天級(jí)別的，最好先算出來再傳進(jìn)去。
select * from foo where date1=current_date -- 不會(huì)被 cache
select * from foo where date1='2008-12-30' -- 被cache, 正確的做法
e) 太大的result set不會(huì)被cache (< query_cache_limit)

2. 何時(shí)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 未必所有場合總是會(huì)改善性能
當(dāng)有大量的查詢和大量的修改時(shí)，cache機(jī)制可能會(huì)造成性能下降。因?yàn)槊看涡薷臅?huì)導(dǎo)致系統(tǒng)去做cache失效操作，造成不小開銷。
另外系統(tǒng)cache的訪問由一個(gè)單一的全局鎖來控制，這時(shí)候大量>的查詢將被阻塞，直至鎖釋放。所以不要簡單認(rèn)為設(shè)置cache必定會(huì)帶來性能提升。
b) 大result set不會(huì)被cache的開銷
太大的result set不會(huì)被cache, 但mysql預(yù)先不知道result set的長度，所以只能等到reset set在cache添加到臨界值 query_cache_limit 之后才會(huì)簡單的把這個(gè)cache 丟棄。這并不是一個(gè)高效的操作。如果mysql status中Qcache_not_cached太大的話, 則可對(duì)潛在的大結(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, 一個(gè)result set的cache通過鏈表把這些block串起來。因?yàn)榇娣舝esult set的時(shí)候并不知道這個(gè)resultset最終有多大。block最短長度為 query_cache_min_res_unit, resultset 的最后一個(gè)block會(huì)執(zhí)行trim操作。
(引用：High Performance MySQL 原書Figure 5-1 插圖)

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

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