关于mysql query cache和memcached…

今天大概地看了下memcached的一些材料，大致了解了它的原理与使用。

给我的感觉就是，对于查询结果的缓存而言，它和mysql的query cache非常的像。 都可以缓存查询的结果以避免重复的查询，最终降低负载。
不同的是：
1. query cache以整个sql语句为key， memcached的key是用户自己定的。
2. query cache自动处理缓存数据的失效问题， memcached需要用户自己去维护，如执行修改语句后需要删除对应的缓存值。
3. query cache位于mysql的server中，共享一个机器的内存，扩展性差； memcached可以独立部署在多台机器上，每台机器上的memcached相互独立，并且支持一致性hash算法，扩展性很强。
4. query cache只支持set，get 和 delete操作，不能对缓存的数据进行除删除和替换以外的修改（如inc，append之类的），灵活性差点；memcached反之。
5. query cache用户基本上无法直接操作它，而memcached在可控制性方面更强点。
6. query cache在mysql的server中，它的最大并发数受到mysql较为复杂的工作线程池的限制，并且必须进行sql语句的解析；而memcached非常的简单轻量，无需为每个连接分配大量的内存，也无需解析sql语句，所以并发处理能力比query cache要强多了。
7. memcached后面会退出本地持久化和主从复制，这些query cache是不可能有的。

综上所述，query cache虽然原理上和memcached很像，但对于单机mysql而言确实不能替代memcached。

但在sqlproxy或之后的dbscale集群中就不一定了。 因为memcached最主要的优势就是上面提到的3、6、7， 而这些都已经有集群来提供了。 以sqlproxy集群为例：
1.sqlproxy运行在后端mysql集群和应用程序之间，作为一个中间件它和memcached一样能够支持远大于单机mysql的并发。通过sqlproxy的分发，最后发到单台mysql上的并发已经很小了，即便很大也可以通过扩充集群的方式减低负载。
2. 就如第一点中说道的那样，由于sqlproxy后端是mysql集群，它本身就是分布式的，所以其中的每个query cache相对于分布式了（因为memcached分布式中各个节点也是完全独立的，所以是一样的。）。扩展性可以通过添加mysql的方式来实现。
3. 主从复制和持久化，这个query cache是不可能有的，但在sqlproxy集群中就不是太重要了。因为每台机器的负载不会很高，而且由于有负载均衡，同一条语句的结果集合可能在多个同为slave机器的的query cache中，所以即便有某太机器挂了，也不会导致集群负载的巨大增加。
4. mysql自动的维护query cache可以简化客户端程序的工作量，并且更高效。


转载请注明出自高孝鑫的博客