统，它保持了自身的结构，而这些结构有助于它了解那块内存是空闲的、表和查询之间的映射关系。查询缓存保留了查询使用过的表，如果表发生了改变，那么缓存就失效了，这样看上去不够高效，某些表的改变不会导致查询结果的改变。但是这种简单方式的开销比较小，而这对于繁忙的系统是很重要的。查询缓存对应用程序完全透明，程序不用知道MySQL是从缓存中返回结果还是通过实际计算返回结果。两种方式返回的结果是一样的，即不会改变语义，不管缓存是打开的还是关闭的，服务器的行为都一样。缓存并不会自动地比非缓存高校。缓存也需要开销，只有在节省的资源大于开销的时候，缓存才是真正有效率的，这和服务器的负载有关。理论上，可以通过对比在缓存开启和关闭时服务器需要做的工作来了解缓存是否有帮助，但实际上很难精确地计算或者预测查询缓存的好处，有时必须考虑外部因素。例如，查询缓存可以减少产生结果的时间，但它不会减少将结果发送到客户端的时间，而这有可能是主要因素。从缓存中受益最多的查询可能是需要很多资源来产生结果，但是不需要很多空间来保存的类型，比如集合查询。所以用于存储、返回和失效的代价都较小。当然也有其他类型的查询值得缓存。检查是否从查询缓存中受益的最简单的办法就是检查缓存命中率，它是缓存提供的查询结果的数量，而不是服务器执行的数量。当服务器收到SELECT语
f句的时候，Qcache_hits和Com_select这两个变量会根据查询缓存的情况进行递增，查询缓存命中率的计算公式是：Qcache_hitsQcache_hitsCom_select。命中率多少才好视情况而定，如果缓存命中率代表了开销最大的查询，那么即使是很低的命中率也有很大的好处。缓存可能会因为碎片、内存不足或数据改变而失效。如果已经给缓存分配了足够的内存，并且把query_cache_mi
_res_u
it调整到了合适的值，那么大部分缓存失效应该是由数据改变引起的。可以通过检查Com_updateCom_delete等的值知道有多少查询修改了数据，也可以通过检查Qcache_lowme
_pru
es的值了解有多少查询因为内存不足而失效。应该监视服务器实际使用的缓存数量，如果它没有用到分配的内存，就应该把分配给它的内存减少一点。如果由于内存限制引起了缓存失效，那么就应该多分配一些内存，但不用太在意缓存的大小，它比有实际影响的稍大一点或小一点都没有问题，只有在内存有严重浪费或缓存失效太多的时候才需要去考虑它的大小，有时还应该在服务器其他缓存和查询缓存之间找到某种平衡。
3调整配置文r