高级特性
查询缓存
什么情况下查询缓存能发挥作用
并不是什么情况下查询缓存都会提高系统性能的。缓存和失效都会带来额外的消耗，所以只有当缓存带来的资源节约大于本身的资源消耗时才会给系统带来性能提升。这跟具体的服务器压力模型有关。理论上，可以通过观察打开或者关闭查询缓存时候的系统效率来决定是否需要开启查询缓存。关闭查询缓存时，每个查询都需要完整的执行，每一次写操作执行完成后立刻返回；打开查询缓存时，每次读请求先检查缓存是否命中，如果命中则立刻返回，否则就完整地执行查询，每次写操作则需要检查查询缓存中是否有需要失效的缓存，然后再返回。这个过程还比较简单明了，但是要评估打开查询缓存是否能够带来性能提升却并不容易。还有一些外部的因素需要考虑，例如，查询缓存可以降低查询执行的时间，但是却不能减少查询结果传输的网络消耗，如果这个消耗是系统的主要瓶颈，那么查询缓存的作用也很小。
因为MySQL再SHOW STATUS中只能提供一个全局的性能指标，所以很难根据此来判断查询缓存是否能够提升性能(Percona和MariaDB对MySQL慢日志进行了改进，会记录慢日志中的查询是否命中查询缓存)。很多时候，全局平均不能反应实际情况。例如，打开查询缓存可以使得一个很慢的查询变得非常快，但是也会让其他查询稍微慢一点点。有时候如果能够让某些关键的查询速度更快，稍微降低一下其他查询的速度是值得的。不过这种情况我们推荐使用SQL_CACHE来优化对查询缓存的使用。
对于哪些需要消耗大量资源的查询通常都是非常适合缓存的。例如一些汇总计算查询，具体的如COUNT()等。总的来说，对于复杂的SELECT语句都可以使用查询缓存，例如多表JOIN后还需要做排序和分页，这类查询每次执行消耗都很大，但是返回的结果集却很小，非常适合查询缓存。不过需要注意的是，涉及的表上UPDATE、DELETE和INSERT操作相比SELECT来说要非常少才行。
一个判断查询缓存是否有效地直接数据是命中率，就是使用查询缓存返回结果占总查询的比率。当MySQL接收到一个SELECT查询的时候，要么增加Qcache_hits的指，要么增加Com_select的值。
所以查询缓存命中率可以由如下公式计算:Qcache_hits/(Qcache_hits+Com_select)
不过，查询缓存命中率是一个很难判断的数值。命中率多大才是好的命中率？具体情况要具体分析。只要查询缓存带来的效率提升大于查询缓存带来的额外消耗，即使30%命中率对系统性能提升也有很大好处。另外，缓存了哪些查询也很重要，例如，被缓存的查询本身消耗非常巨大，那么即使缓存命中率非常低，也仍然会对系统性能提升有好处。所以，没有一个简单的规则可以判断查询缓存是否对系统有好处。
任何SELECT语句没有从查询缓存中返回都成为"缓存未命中"。缓存未命中可能有如下几种原因:
- 1.查询语句无法被缓存，可能是因为查询种包含一个不确定的函数(如CURRENT_DATE)，或者查询结果太大而无法缓存。这都会导致状态值Qcache_not_cached增加
- 2.MySQL从未处理这个查询，所以结果也从不曾被缓存过
- 3.还有一种情况是虽然之前缓存了查询结果，但是由于查询缓存的内存用完了，MySQL需要将某些缓存"逐出"，或者由于数据表被修改导致缓存失效。
如果你的服务器上有大量缓存未命中，但是实际上绝大数查询都被缓存了，那么一定是有如下情况发生:
- 1.查询缓存还没有完成预热。也就是说，MySQL还没有机会将查询结果都缓存起来。
- 2.查询语句之前从未执行过，如果你的应用程序不会重复执行一条查询语句，那么即使完成预热仍然会有很多缓存未命中
- 3.缓存失效操作太多了
缓存碎片、内存不足、数据修改都会造成缓存失效。如果配置了足够的缓存空间，而且query_cache_min_res_unit设置也合理的化，那么缓存失效应该主要是数据修改导致的。可以通过参数Com_*来查看数据修改的情况(包括Com_update,Com_delete，等等)，还可以通过Qcache_lowmem_prunes来查看多少次失效是由于内存不足导致的。
在考虑缓存命中率的同时，通常还需要考虑缓存失效带来的额外消耗。一个极端的办法是，对某一个表先做一次只有查询的测试，并且所有的查询都命中缓存，而另一个相同的表只做修改操作。这是，查询缓存的命中率就是100%。但因为会给更新操作带来额外的消耗，所以查询缓存并不一定会带来总体效率的提升。这里，所有的更新语句都回做一次缓存失效检查，而检查的结果都是相同的，这会给系统带来额外的资源浪费。所以，如果你只是观察查询缓存的命中率的话，可能完全不会发现这样的问题。
在MySQL张入股更新操作和带缓存的读操作混合，那么查询缓存带来的好处通常很难很亮。更新操作会不断地使得缓存失效，而同时每次查询还会像缓存中再写入新的数据。所以甚至有当后续的查询能够在缓存失效前使用缓存才会有效地利用查询缓存。
如果缓存的结果在失效前没有被任何其他的SELECT语句使用，那么这次缓存操作就是浪费时间和内存。我们可以通过查看Com_select和Qcache_inserts的相对值来看看是否一直有这种情况发生。如果每次查询查询都是缓存未命中，然后需要将查询结果放到缓存中，那么Qcache_inserts的大小应该和Com_select相当。所以在缓存完成预热后，我们总希望看到Qcache_inserts远远小于Com_select。不过由于缓存和服务器内部的复杂和多样性，仍然很难说，这个比率是多少才是一个合适的值。
所以，上面的"命中率"和"INSERTS和SELECT比率"都无法直观地反应查询缓存的效率，那么还有什么直观的办法能够反应查询缓存是否对系统有好处？这里推荐查看一个指标"命中和写入"的比率。即Qcache_hits和Qcache_inserts的壁纸。根据经验来看，当这个比值大于3:1时通常查询缓存是有效的，不过这个比率最好能够达到10:1.如果你的应用没有达到这个比率，那么就可以考虑禁用查询缓存了。除非你能够通过精确的计算得知:命中带来的性能提升大于缓存失效的消耗，并且查询缓存并没有成为系统的瓶颈。
每一个应用程序都会有一个"最大缓存空间"，甚至对一些纯读的应用来说也一样。最大缓存空间是能够缓存所有可能查询结果的缓存空间综合。理论上，对多数应用来说，这个数值都会非常大。而实际上，由于缓存失效的原因，大多数应用最后使用的缓存空间都比预想的要小。即使你配置了足够大的缓存空间，由于不断地失效，导致缓存空间一直都不会接近"最大缓存空间"。
通常可以观察查询缓存内存的实际使用情况，来确定是否需要缩小或者扩大查询缓存。如果查询缓存空间长事件都有剩余，那么建议索引；如果经常由于空间不足而导致查询缓存失效，那么则需要增大查询缓存。不过需要注意，如果查询缓存达到了几十兆这样的数量级，是有潜在危险的。
另外，可能还需要和系统的其他缓存一起考虑，例如InnoDB的缓存池，或者MyISAM的索引缓存。关于这点是没法简单给出一个公式或者比率来判断的，因为真正的平衡点与应用程序有很大的关系。
最好的判断查询缓存是否有效的办法还是通过查询某类查询时间消耗是否增大或者减少来判断。Percona Server通过扩展慢查询可以观察到一个查询是否命中缓存，如果查询缓存没有为系统节省时间，那么最好禁用它
