mysql实战优化之九：MySQL查询缓存总结
mysql Query Cache 默认为打开。从某种程度可以提高查询的效果，但是未必是最优的解决方案，如果有的大量的修改和查询时，由于修改造成的cache失效，会给服务器造成很大的开销。
mysql Query Cache 和 Oracle Query Cache 是不同的， oracle Query Cache 是缓存执行计划的，而MySql Query Cache 不缓存执行计划而是整个结果集。缓存整个结果集的好处不言而喻，但由于缓存的是结果集因此Query必须是完全一样的，这样带来的后果就是平均 Hit Rate 命中率一般不会太高。 Query Cache 对于一些小型应用程序或者数据表的数据量不大的情况下效果是最为明显的。
一、mysql Query Cache管理
1.1、query cache开关
可以通过query_cache_type来控制缓存的开关， query_cache_type的状态值有如下几种：
- 0(OFF)：代表不使用缓冲；
- 1(ON)：代表使用缓冲；
- 2(DEMAND)：代表根据需要使用；
show variables like '%query_cache%';
1.2、query_cache_size
默认情况下query_cache_size为0，表示为查询缓存预留的内存为0，则无法使用查询缓存。这个值必须是1024的整数倍。否则，mysql实际分配的数据会和你指定的不同。
所以我们需要设置query_cache_size的值：
SET GLOBAL query_cache_size = 134217728;
注意上面的值如果设得太小不会生效。比如我用下面的SQL设置query_cache_size大小：
SET GLOBAL query_cache_size = 4000;
query_cache_limit
mysql能够缓存的最大查询结果。如果查询结果大于这个值，则不会被缓存。缺省为1M。因为查询缓存在数据生成的时候就开始尝试缓存数据，所以只有当结果全部返回后，mysql才知道查询结果是否超出限制。
如果超出，mysql则增加状态值Qcache_not_cached，并将结果从查询缓存中删除。
如果你事先知道有很多这样的情况发生，那么建议在查询语句中加入SQL_NO_CACHE来避免查询缓存带来的额外消耗。
query_cache_wlock_invalidate
如果某个数据表被其他的连接锁住，是否还要从查询缓存中返回结果。这个参数默认是OFF，这可能在一定程度上回改变服务器的行为，因为这使得数据库可能返回其他线程锁住的数据。
如果设置为NO，则不会从缓存中读数据，但是这可能会增加锁等待。
query_cache_min_res_unit
是在4.1版本以后引入的，它指定分配缓冲区空间的最小单位，缺省为4K。检查状态值Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多，这就表明查询结果都比较小，此时需要减小 query_cache_min_res_unit。
1.3、SHOW WARNINGS;
二、mysql query cache规则
2.1、缓存条件（规则）
需要注意的是mysql query cache 是对大小写敏感的，因为Query Cache 在内存中是以 HASH 结构来进行映射，HASH 算法基础就是组成 SQL 语句的字符，所以 任何sql语句的改变重新cache,这也是项目开发中要建立sql语句书写规范的原因吧。
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.2、 缓存数据何时失效（invalidate）
在表的结构或数据发生改变时，查询缓存中的数据不再有效。有这些INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE会导致缓存数据失效。所以查询缓存适合有大量相同查询的应用，不适合有大量数据更新的应用。
a) 一旦表数据进行任何一行的修改，基于该表相关cache立即全部失效。
b) 为什么不做聪明一点判断修改的是否cache的内容？因为分析cache内容太复杂，服务器需要追求最大的性能。
2.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
2.4、内存池使用
mysql query cache 使用内存池技术，自己管理内存释放和分配，而不是通过操作系统。内存池使用的基本单位是变长的block, 一个result set的cache通过链表把这些block串起来。因为存放result set的时候并不知道这个resultset最终有多大。block最短长度为 query_cache_min_res_unit, resultset 的最后一个block会执行trim操作。
Query Cache 在提高数据库性能方面具有非常重要的作用。
其设定也非常简单，仅需要在配置文件写入两行： query_cache_type 和 query_cache _size，而且 MySQL 的 query cache 非常快！而且一旦命中，就直接发送给客户端，节约大量的 CPU 时间。
当然，非 SELECT 语句对缓冲是有影响的，它们可能使缓冲中的数据过期。一个 UPDATE 语句引起的部分表修改，将导致对该表所有的缓冲数据失效，这是 MySQL 为了平衡性能而没有采取的措施。因为，如果每次 UPDATE 需要检查修改的数据，然后撤出部分缓冲将导致代码的复杂度增加。
三、示例说明
3.1、如果query_cache_type为1而又不想利用查询缓存中的数据
可以用下面的SQL：
SELECT SQL_NO_CACHE * FROM my_table WHERE condition;
3.2、如果值为2，但想要使用缓存
SELECT SQL_CACHE * FROM my_table WHERE condition;
用 SHOW STATUS 可以查看缓冲的情况：
mysql> show status like 'Qca%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Qcache_queries_in_cache | 8 | | Qcache_inserts | 545875 | | Qcache_hits | 83951 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 2343256 | | Qcache_free_memory | 33508248 | | Qcache_free_blocks | 1 | | Qcache_total_blocks | 18 | +-------------------------+----------+ 8 rows in set (0.00 sec)
如果需要计算命中率，需要知道服务器执行了多少 SELECT 语句：
mysql> show status like 'Com_sel%'; +---------------+---------+ | Variable_name | Value | +---------------+---------+ | Com_select | 2889628 | +---------------+---------+ 1 row in set (0.01 sec)
在本例中， MySQL 命中了 2,889,628 条查询中的 83,951 条，而且 INSERT 语句只有 545,875 条。因此，它们两者的和和280万的总查询相比有很大差距，因此，我们知道本例使用的缓冲类型是 2 。
而在类型是 1 的例子中， Qcache_hits 的数值会远远大于 Com_select。
