MySQL Query Cache 看上去很美

来公司没多久，之前前辈已经搭建好Mysql数据库和运行着一些APP接口。今天老大说需要对数据做一些更改，特别提示之前数据库使用ＣＡＣＨＥ，不知道这部分会不会有影响。有点蒙了，因为之前一直用Redis，数据本身的Cache听都没听说。赶紧百度呗，得知开户Query Cache办法是在my.cnf中配置query_cache_type选项，然后我就跑去查看配置文件，发现根本没配置这一选项，那查看Redis，也没有相关的缓存呀，老大，你是不是又被我的前辈坑了？

好吧，既然说到MySQL Query Cache，那就了解一下吧。过程看到很多人说不建议使用，数据更新少查询多的话才适用。下面引用网友的文字，原著是谁也不知道，大家都复制来复制去的。引用：

当你的数据库打开了Query Cache(简称QC)功能后，数据库在执行SELECT语句时，会将其结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。

　　在这个“Cache为王”的时代，我们总是通过不同的方式去缓存我们的结果从而提高响应效率，但一个缓存机制是否有效，效果如何，却是一个需要好好思考的问题。在MySQL中的Query Cache就是一个适用较少情况的缓存机制。在上图中，如果缓存命中率非常高的话，有测试表明在极端情况下可以提高效率238%[1]。但实际情况如何?Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。举个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么Query Cache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%[1]的处理能力。
　　如果你的应用对数据库的更新很少，那么QC将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候QC的作用会比较明显。
　　再如，一个更新频繁的BBS系统。下面是一个实际运行的论坛数据库的状态参数：
QCache_hit	5280438
QCache_insert	8008948
Qcache_not_cache	95372
Com select	8104159
　　可以看到，数据库一共往QC中写入了约800W次缓存，但是实际命中的只有约500W次。也就是说，每一个缓存的使用率约为0.66次。很难说，该缓存的作用是否大于QC系统所带来的开销。但是有一点是很肯定的，QC缓存的作用是很微小的，如果应用层能够实现缓存，将可以忽略QC的效果。

本人也懒得做测试，也生怕使用 MySQL Query Cache会带来什么未知问题，何况现使用Redis挺好，自己规划好缓存标签，更新数据时候只删除相关缓存！所以决定维持现况，弃用Query Cache。