Query Cache

1. 存储Query，并且存储result
2. cache会跟踪哪些table被使用了，是否被修改了，
3. 对应用程序透明
4. 使用hash去查找；任何大小写、空格、注释都会影响命中
   结果需要是确定性的：now() current_user() current_date() result都不会被缓存
5. 会增加系统负载，一般不大：check cache；缓存结果；数据被更新，需要使cache过期   
   对于InnoDB来讲，如果一个事务修改了一张表，那么cache中table相关query是要置为无效的，而且在事务期间都不能被cache
   如果cache中query过多，置为无效也需要一定时间(可能很长)
   
Cache如何使用内存
1. 40K固定大小的常用内存，使用可变长的block，每个block知道他的类型(result,query使用哪些表，query文本)、大小、记录数
2. 使用时首先分配query_cache_min_res_unit，不会分精确，因为result set在它分配后才会定下来(不是一起传给内存，而是生成一条row传一条)
3. 如果有并发查询，分配的大小不合适，慢慢会增加内存碎片,碎片太小不能用于其他缓存
 
cache是否有效
1. Hit rate：cache中的query/server执行的query；Qcache_hits/(Qcache_hits+Com_select)
2. cache miss的原因
query不能cache：含有不确定结果now()；结果集太多 两种情况都会增加Qcache_not_cached 
没执行过
数据过期 被server删掉
3. 如果cache miss多，而uncachable query不多：
server刚启动，还没开始缓存
没执行过的query很多
cache失效很多（碎片，内存不够，数据修改）
数据修改记录（Com_* status Com_update, Com_delete等）
由于低内存而导致的无效query数量：Qcache_lowmem_prunes
4. query cache会增加update的负载：每个update都会去cache查看是否有query需要置为invalid
5. 如果com_select与Qcache_insert相同说明失效过多，Qcache_insert应该比com_select小很多
com_select等于qcache_inserts(失效) + qcache_not_cache + 权限检查错误的
qcache_inserts这个计数不是表示没被缓存而进行的读，而是缓存失效而进行的读，没被缓存和缓存失效是两个概念，分别计数，但都会引起com_select
6. 调试维护Query Cache
query_cache_type：是否开启cache(OFF, ON,or DEMAND),第三个只有在sql中定义了SQL_CACHE才会缓存
query_cache_size：cache分配的全部内存大小，单位K
query_cache_min_res_unit：block最小单位
query_cache_limit：可以被cache的最大结果集
query_cache_wlock_invalidate：默认off，一个connection可以读另外一个connection锁定表的数据
减少碎片
无法完全避免，但是精心选择query_cache_min_res_unit可以避免浪费内存
需要在分配大小与数量之间找平衡(过小，会分配过多，增加cpu负担；过大 碎片多)
cache中query平均大小:(query_cache_size – Qcache_free_memory)/Qcache_queries_in_cache
通常缓存大result都没啥好处，通过query_cache_limit限制
Qcache_free_blocks：Free的block；达到Qcache_total_blocks/2冲突会激烈；Qcache_lowmem_prunes在增加但是有很多FreeBlock就是碎片引起的query被cache删除
FLUSH QUERY CACHE会减少碎片，但是cache此时不可访问
RESET QUERY CACHE会清空cache
改善cache使用
如果无碎片但是hit还是不高，可能是内存分配不够，她回挤掉其他缓存的query：Qcache_lowmem_prunes增加
未使用的内测：Qcache_free_memory
如果很多freeBlock 碎片也不多 被挤掉也不多：频繁更新，不可缓存
不确定cache是否有益：query_cache_size设为0，测benchMark
7. InnoDB和Query Cache
InnoDB使用MVCC，在4.0之前完全禁用cache，4.1开始由InnoDB通知server(基于每张表)事务是否可以访问cache(从cache读，吧result写入cache)
访问控制通过：事务ID 表是否有锁；每个表在内存中的数据字典都有一个对应的事务id号，比这个id号小的事务是不能读写cache中与表相关的query的
。。。。。。 没看懂，需要在研究
8. 常用的优化方案
多张小表而不是一张大表有助于缓存
批量写比一条一条写有效，因为只invalide cache一次
在invalide和排挤其他query时 server会延迟很长一段时间，所以不要把query_cache_size设的太大，256M足矣
不能在db或表级别限制cache，但是可以在sql中声明SQL_CACHE and SQL_NO_CACHE；session level的query_cache_type可以限制到connection级别是否做cache
在写逻辑频繁的系统，禁用cache性能会得到提升
9. Query cache的可选方案
client cache