数据库中有两个表的更新频率非常高，这种情况下适用memcache吗

数据库中有两个表的更新频率非常高，一个记录有可能在5分钟内更新5个状态，而且这两个表关联的，经常用到链表查询，在用户比较多的情况下，如果不适用缓存，网站访问起来非常的慢，所以请教大师，这种情况下怎样应用缓存，缓解一下数据库的压力。我在看一个memcache的东西，描述是很精彩，但是不知道在适不适合我这种情况，在这方面没有经验，请大师指导指导。谢谢先

5 个解决方案

#1

你可以把这两个表用memory 存储引擎。

http://dev.mysql.com/doc/refman/5.1/zh/storage-engines.html#memory-storage-engine
15.4. MEMORY (HEAP)存储引擎


MEMORY表有下列特征： 

·         给MEMORY表的空间被以小块来分配。表对插入使用100%动态哈希来。不需要溢出区或额外键空间。*列表无额外的空间需求。已删除的行被放在一个以链接的列表里，并且在你往表里插入新数据之时被重新使用。MEMORY表也没有通常与在哈希表中删除加插入相关的问题。 

·         MEMORY表可以有多达每个表32个索引，每个索引16列，以及500字节的最大键长度。 

·         MEMORY存储引擎执行HASH和BTREE索引。你可以通过添加一个如下所示的USING子句为给定的索引指定一个或另一个： 

#2

memory好像是说有存储大小的限制吧（内存）,那两个表的数据可是不小的。400~500M

#3

数据量达到几百万了？

一般建好索引，优化sql是没啥问题的

如果数据上千万了，考虑分表，集群等技术

不是大公司，估计用不上

#4

Cache的使用与否，最重要的一个判别因素就是 读写比。无论是数据库的cache，还是动态生成的网页内容，读写比太低，反而成了累赘，不如不要。

就你的例子而言，如果一条记录5分钟更新5次（指平均情况，极端情况不在此列）平均一分钟更新一次，除非是超大型的网站或者这个状态时效性实在不重要，否则读写比貌似不高，失去了cache的意义

关于两个表关联查询的问题，如果数据量较大的话，楼上说的分表可能是必要的一步。分表的依据可以是时间、区域或者其他业务字段，但尽量遵循一个原则，即绝大部分查询，在查数据库之前，就已经可以确定要访问哪张表。换言之，查询的结果应当尽量都落在单张表中。

此外，可能还要加一些辅助字段/表，用来记录本来需要通过SQL查询才能得到的统计状态，来起到类似cache的总用，提高速度。比如，一张表是客户信息，一张表是通话记录。通话记录中有通话时间。如果一个常用的查询是找出所有最长通话时间超过5分钟的客户，那么，应当在客户表中加上一个字段来记录这样的信息，或者索性建立一张表（客户ID，最长通话时间，最短通话时间，最后通话电话号码）。

#5

挺适合的。

MEMCACHED 的内存限制取决于您机器的物理内存！