1. 何时cache
a) mysql query cache内容为 select 的结果集, cache 使用完整的 sql 字符串做 key, 并区分大小写，空格等。即两个sql必须完全一致才会导致cache命中。
b) prepared statement永远不会cache到结果，即使参数完全一样。据说在 5.1 之后会得到改善。
c) where条件中如包含了某些函数永远不会被cache, 比如current_date, now等。
d) date 之类的函数如果返回是以小时或天级别的，最好先算出来再传进去。
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) 一旦表数据进行任何一行的修改，基于该表相关cache立即全部失效。
b) 为什么不做聪明一点判断修改的是否cache的内容？因为分析cache内容太复杂，服务器需要追求最大的性能。
3. 性能
a) cache 未必所有场合总是会改善性能
当有大量的查询和大量的修改时，cache机制可能会造成性能下降。因为每次修改会导致系统去做cache失效操作，造成不小开销。
另外系统cache的访问由一个单一的全局锁来控制，这时候大量>的查询将被阻塞，直至锁释放。所以不要简单认为设置cache必定会带来性能提升。
b) 大result set不会被cache的开销
太大的result set不会被cache, 但mysql预先不知道result set的长度，所以只能等到reset
set在cache添加到临界值 query_cache_limit 之后才会简单的把这个cache 丢弃。这并不是一个高效的操作。如果mysql
status中Qcache_not_cached太大的话, 则可对潜在的大结果集的sql显式添加 SQL_NO_CACHE 的控制。
query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache
4. 内存池
使用
mysql query cache 使用内存池技术，自己管理内存释放和分配，而不是通过操作系统。内存池使用的基本单位是变长的block,
一个result set的cache通过链表把这些block串起来。因为存放result
set的时候并不知道这个resultset最终有多大。block最短长度为 query_cache_min_res_unit,
resultset 的最后一个block会执行trim操作。
(引用：High Performance MySQL 原书Figure 5-1 插图)
定长：空间浪费
变长：需清理碎片
block 小： 链表超长，访问大块数据效率低。
另外发现 surfchen 的 MySQL的Query Cache
对这方面的内容描述也不错，可以和本文互为补充。