我们经常在项目中遇到的需求就是计算在一周内的记录总数，而且这个数目是需要在列表页出现的，所以用SELECT COUNT显然不合适。
但是如果你用缓存来做的话，因为这个值是根据你的当前时间不断在变的，比如用户在下午14:10来访问这个页面，那么我们要计算的就是从7天前的14:10到现在这段时间内的记录总数。这是不可能缓存的，我不知道各位是怎么设计的。
我有一个思路就是，还是用SELECT COUNT来统计，但是把它缓存住，一个小时更新一次。看起来解决的还可以，不知道各位有什么更好的思路，比这个准确度更高的。
维护一个队列，队列的每个元素是记录产生的时间：
1. 每当一个新纪录产生时，入队。更新队列的元素总数。
2. 每当来一次查询的时候，计算起始时间t，将所有小于t的记录出队。更新队列的元素总数。返回队列的元素总数。
优点：高效、精确。
缺点：占用一定的内存，对于100万个元素需要约4MB的内存空间。
p.s. 这个算法可以很容易地用mysql表来实现。
不断变化，还是count比较好吧，你缓存还不要断更新缓存。
因为这个值是根据你的当前时间不断在变的。
还有你实际上每时每刻都要重新计算，因为14:00访问，14:01访问，14:02访问得到的数据都需要重新计算，都可能发生变化。
不过要是只是统计7天的数据，你倒是可以缓存一下，当前时间超过7天的就从缓存中删除，然后不断更新对应时间段的缓存。
可是有一个问题，如果按照时间段来缓存count，你可能会同时更新n个缓存。
应该是到分钟级别就够了吧。那就每分钟更新一次缓存就行了。
例如：13：59时刻统计的访问量是N，当前时间是 14：00, 计算13:59-14:00的记录数为n1(select count)，然后计算7天前13:59-14:00的记录数为n2(select count)。那么现在的访问量就为N+n1-n2。
你要不创建一个trigger和一张表用来记录行数，如果你的入数据库的量不大的话。 比如
ON INSERT UPDATE counter SET table_name_count = table_name_count + 1 ;
然后前台读取的时候从那张表读就是了。
不过也要看你用的是什么SQL了， MySQL的 MyISAM 对这个问题是做了优化的； 就直接SELECT COUNT就是了。