memcache or mysql memory engine

一般说来，我们的rails应用都会使用mysql，用memcache做缓存。不过mysql支持memory类型的引擎，和memcache有些相似。
网上有篇文章说到了他们的比较：http://hi.baidu.com/jabber/blog/item/757873f455cf32d9f2d385eb.html

但我仍然不是很清楚，memory table可以进行关系操作，而memcache不适合，而我们常常进行查询操作，那意味着memcache不象原来想的那么常用？还是我对REST的理解不够？
至于memory table的使用，我也不熟悉，不知道通常是如何保存数据的，难道停机之前写个脚本导出？

memcached是用来做Cache的，不是用来保存数据的。MySQL内存表你不能用它来做Cache，它应用于一些需要高性能读写的特殊场合。

概念上其实容易说明，只不过具体执行的时候还是有问题，例如，如果你发现性能有瓶颈，是把一个表改为memory，还是用memcache缓存对象呢？

如果性能瓶颈是数据库查询引起的，当然需要增加memcached对象缓存了；如果性能瓶颈在于高并发的频繁对某个小表的插入和更新操作造成的表锁定的话，可以考虑使用内存表解决。

其实这两者应用的场合是不同的，需要解决的问题域也不是同一回事。比方说JavaEye使用了memcached提供对象缓存，可以很大程度上降低应用对数据库的SQL查询负载，但此时你用内存表是不解决问题的。JavaEye也使用了内存表来记录用户在线状态，可以实时显示究竟有多少注册会员在线，究竟在干什么，阅读过什么帖子，这种需要极频繁更新操作，并且还需要查询支持的情况你用memcached是无法提供的。

嗯，现在思路清晰一些了，目前的现实问题就是一些计数方面的性能问题，我考虑做一个counter表，memory engine，然后从它取到的东西就可以做cache了
AR的update应该是行锁定吧，以后根据需要可以分裂这个counter表

counter表可以用内存表，因为counter这玩意更新太频繁了，用普通的数据库表对硬盘IO带来的压力太大。但你要注意两个问题：

1、数据库重起，内存表就清空了，你得有一个机制定期把内存的counter flush到硬盘表

2、MySQL的内存表是很费内存的，如果你内存表有varchar(4000)这样的字段，每插入一条记录，就会实际分配4000字节的内存空间，几万条这样的记录，你的内存就吃不消了，而且内存表默认只用16MB内存，你可能要自己设置的更大。

新浪的开发人员搞了一个memcachedb项目，也可以用来实现counter这类操作，如果你不需要做统计查询，也可以用memcachedb。