不知道各位有什么更好的思路，比下面这个准确度更高的？

Question

我们经常在项目中遇到的需求就是计算在一周内的记录总数，而且这个数目是需要在列表页出现的，所以用SELECT COUNT显然不合适。但是如果你用缓存来做的话，因为这个值是根据你的当前时间不断在变的，比如用户在下午14:10来访问这个页面，那么我们要计算的就是从7天前的14:10到现在这段时间内的记录总数。这是不可能缓存的，我不知道各位是怎么设计的。我有一个思路就是，还是用SELECT COUNT来统计，但是把它缓存住，一个小时更新一次。

Answer 1

你要不创建一个trigger和一张表用来记录行数，如果你的入数据库的量不大的话。 比如
ON INSERT UPDATE counter SET table_name_count = table_name_count + 1 ;
然后前台读取的时候从那张表读就是了。

不过也要看你用的是什么SQL了， MySQL的 MyISAM 对这个问题是做了优化的； 就直接SELECT COUNT就是了。

Answer 2

维护一个队列，队列的每个元素是记录产生的时间：

1. 每当一个新纪录产生时，入队。更新队列的元素总数。

2. 每当来一次查询的时候，计算起始时间t，将所有小于t的记录出队。更新队列的元素总数。返回队列的元素总数。

优点：高效、精确。
缺点：占用一定的内存，对于100万个元素需要约4MB的内存空间。

p.s. 这个算法可以很容易地用mysql表来实现。

Answer 3

不断变化，还是count比较好吧，你缓存还不要断更新缓存。
因为这个值是根据你的当前时间不断在变的。
还有你实际上每时每刻都要重新计算，因为14:00访问，14:01访问，14:02访问得到的数据都需要重新计算，都可能发生变化。
不过要是只是统计7天的数据，你倒是可以缓存一下，当前时间超过7天的就从缓存中删除，然后不断更新对应时间段的缓存。
可是有一个问题，如果按照时间段来缓存count，你可能会同时更新n个缓存。