如题：
每个sns网站中都有好友动态 在用户登陆上来以后 能看到自己好友的最近的动作 --
这个需求看起来并不是非常困难
1；单独设置一张表记录用户的动作
缺点：1.1；但是数据一旦大起来 访问量也上升就带来了问题 连表查询的速度不是很快
1.2；用户不能删除好友动态
2；在上面基础上增加一张好友动态删除表
缺点：还是数据量的问题，一但运行一段时间之后，是否要做一下清除呢？如果清除，那么其不损失掉大量数据吗？对于网站来说，数据是最为重要的资源,而且，在 某些长时间未登陆的情况下，动态数据其不要经常为空吗？求助：------ 各位大虾们有没有什么好的解决方法呢？
每个sns网站中都有好友动态 在用户登陆上来以后 能看到自己好友的最近的动作 --
这个需求看起来并不是非常困难
1；单独设置一张表记录用户的动作
缺点：1.1；但是数据一旦大起来 访问量也上升就带来了问题 连表查询的速度不是很快
1.2；用户不能删除好友动态
2；在上面基础上增加一张好友动态删除表
缺点：还是数据量的问题，一但运行一段时间之后，是否要做一下清除呢？如果清除，那么其不损失掉大量数据吗？对于网站来说，数据是最为重要的资源,而且，在 某些长时间未登陆的情况下，动态数据其不要经常为空吗？求助：------ 各位大虾们有没有什么好的解决方法呢？
CSDN有这功能
UCHOME好象就没有
1.用一个表，专门储存用户状态；
2.用户每访问一个目标action模块，自动向表内添加状态信息；
3.每隔一段时间，对状态表内容进行清楚。如果说难的话，就是在设计上。
例如，用户有什么状态，每个状态如何显示；
还有就是程序结构上的，如何给众多action模块添加这个固定的处理。
from user_action
where
user_action.user_id in
(
select user_friend.friend_id
from user_friend
where user_friend.user_id='".$user_id."'
)
limit 0,100user_action：用户操作表
user_action.user_id：用户操作表.用户id
user_friend：用户好友表
user_friend.friend_id:用户好友表.好友id
user_friend.user_id:用户好友表.用户id====================
这个不需要即时的吧，不会搞得和即时通信一样把
那每个查询的sql结果，生成个缓存数据，在一个文本
每次，如文本最后修改时间，30分钟之前的，重新查询，否则用缓存
重查的时候，也可以加上，删除1周前的数据 的操作，这样可行？用户不能删除好友动态，
可以加个标记字段，说明 已阅，以后查询时过滤掉之类某些长时间未登陆的情况下，动态数据其不要经常为空吗？
那是否可以考虑，写这张表的时候，user_action
用replace into ,只记录最新的，比如5条操作，这样这表也不用删除了，可行？
改进下：select *
from user_action
where
user_action.user_id in
(
select user_friend.friend_id
from user_friend
where user_friend.user_id='".$user_id."'
order addtime desc
limit 20
)
limit 0,100
============================================
1.用户不能删除好友动态，
可以加个标记字段，说明 已阅，以后查询时过滤掉之类-》
这个显然是不可行的：原因：好友关系并不是一一对应的，而是多对多的，既一个好友id可能同时关联多个uid，除非有另外的一张状态table来记录此用户对应的好友动态状态~~~~~~~~~~~~汗！！！！！！
2.那每个查询的sql结果，生成个缓存数据，在一个文本
每次，如文本最后修改时间，30分钟之前的，重新查询，否则用缓存 -》
此方法可行，但是时间间隔是个问题，动态关键在于实时性，30分钟会不会太常呢？？？？？
3.用replace into ,只记录最新的，比如5条操作-》
什么意思？？？？？不明白？
第二步：可以设置成可屏蔽的，既可针对不同的好友来返回结果，也可通过limit等条件限定
第三步：理论上，的确所有用户动态均记录在此表，这正是问题的根源所在~~~~~~~~但是，目前为至，似乎还没有更好的结构设计！！！！！！！！！汗~~~~~~~~~`
如果多张表，查询效率就会很高！uchome就没有上面的功能
此外，在好友动态上，uchome默认是30天的数据，其他的清空CSDN所有数据好象是永久保存的！至少原始数据的数据都是保存的！
不是这里有有CSDN的朋友吗？希望也谈谈设计和优化原理！
汗~~~~~~~~~~~~~~
分表吧，一个月一张user_action 表
所有记录都在，同时，通常查询时，是最新的这张表，速度也不成问题
这也不太好？被选集想无限多，选择时想最快，真所谓冰炭不同器，一杆秤想同时达到2个极端，不能两全，
只有找平衡点，无论是分表/保留最少的纪录/缓存/等，都是在找平衡点
有道是冰火两重天，也需轮询交替，才能阴阳调和……
不求最好，但求正好，是我们一生的追求……
话说100万用户，竟然人人每天都跑到网站来，每人还都必做5次以上的数据操作，据业内消息灵通人士称，此时网站仅垃圾广告收入少说50万/月，听的我哈喇子流了一地……
届时我早下辖 3/4/5个团队，其中n个专门负责 负载均衡，我也由1/2/3转后成为贵族，主要工作变成数钱……啥子好友动态数据，都不要来烦我，直接无视，无欲则刚……
另据不可考消息，为每个用户建立一个文件夹……
每个文件下，有一个friend_aciton文件夹
每当一个用户操作后，找到其所有好友，的文件夹，往下属的friend_aciton文件夹，加一条记录文本
酱紫，每个用户只要读自己文件夹下的，friend_aciton文件夹里的记录就行了……
我的天天，这不就是传说中的垃圾邮件群发吗……
foreach($friends as $id=>$info)
$str .= $id.'-0';比如 select * from updating where concat(id,'-',type) in ($str);
对于删除 目前主流的做法 应该是不支持对非自己动态的删除 一般都是采用屏蔽的方式 对于自己的动态才可以删除采用屏蔽的方式 只要建立个屏蔽数组 记录屏蔽的用户ID （或者动态类型） 在 上面的 foreach 循环中 判断在 屏蔽数组就不拼接语句。这个方案的缺点是好友多时候 频出的 SQL 过长 但是 一般 千百个好友是支持的 。过长 你可以搜索下 论坛里面有个 关于 sql 长度限制问题的帖子。