用户信息表(t_user_info)字段名称字节数类型描述
User_id4uint32用户编号(主键)
User_name20Char[20]名称
Msg_count4uint32发布消息数量,可以作为t_msg_info水平切分新表的auto_increment
Fans_count4uint32粉丝数量
Follow_count4Uint32关注对象数量
备注：以User_id取模分表
用户之间关系表(t_user_relation),必须有关注与被关注的关系字段名称字节数类型描述
User_id4uint32用户编号(联合主键)
Follow_id4uint32被关注者编号(联合主键)
Type1Uint8关系类型(0，粉丝；1，关注)
备注：关系是单向的，以User_id取模分表
用户消息索引表(t_uer_msg_index)字段名称字节数类型描述
User_id4uint32用户编号(联合主键)
Author_id4uint32消息发布者编号(可能是被关注者，也可能是自己)(联合主键)
Msg_id4uint32消息编号(由消息发布者的msg_count自增)(联合主键)
Time_t4Uint32发布时间(必须是消息元数据产生时间)
备注：此表就是当我们点击“我的首页”时拉取的消息列表，只是索引，Time_t对这些消息进行排序
消息与消息关系表(t_msg_msg_relation)字段名称字节数类型描述
Reference_id4uint32引用消息用户编号(联合主键)
Reference _msg_id4uint32引用消息编号(联合主键)
Referenced_id4uint32消息发布者编号
Referenced _msg_id4uint32被引用消息编号
Type1Uint8操作类型(1,评论；2，转发)
Time_t4Uint32发布时间
Page_index4Uint32转发或者评论页码
备注：以Reference_id取模分表。
腾讯微博比新浪微博好的一点是一个消息的所有评论和转发都是被固定页码，这样在点击看评论的时候搜索效率更高，因为多了一个where Page_index的定位条件，当然带来的问题就是可能看到有些页的评论排版并不是满页，这就是因为标识为这个Page_index的评论有删除操作。
消息元数据表(t_msg_info)字段名称字节数类型描述
User_id4uint32发消息用户编号(联合主键)
Msg_id4uint32消息编号(联合主键)
Content140Char[140]消息内容
Type1Uint8消息类型(0，原创；1，评论；2，转发)
Commented_count4Uint32评论过数量(只增不减，删除评论不影响此值，可以作为评论多页显示的页码)
Comment_count4Uint32保留的评论数量
Transferred_count4Uint32转发过数量(只增不减，删除转发不影响此值，可以作为转发多页显示的页码)
Transfer_count4Uint32保留的转发数量
Time_t4Uint32发布时间
备注：消息元数据中，content像可能存在图片，这部分可以在分布式文件系统中存储。在2011年数据库大会上听杨海潮的演讲，对于nosql 也有涉及，本人能力有限，对这部分的职责还不清楚，希望高人指点。
非常推崇杨海潮ppt中的归档做法，因为微博是有时间轴线的，对于一定时间之前的记录可以分层次归档，这样在前端的最新的数据表的压力就会减轻很多。
业务逻辑：
1.A关注B
1)在t_user_relation_A中添加AB1
2)在t_user_relation_B中添加
BA0
2.原创发消息
1)在t_msg_info_A中添加这条元消息，type为0
2)更新t_user_info_A中Msg_count
3)在t_uer_msg_index_A中插入A发的这条消息的索引(A的编号和消息编号)
4)在t_user_relation_A中找到所有关注A的人，比如B,C,D,E,F等等，并发在这些用户的t_uer_msg_index中插入A的这条信息索引，比如名人微博可以并发多个进程来实现对粉丝的消息同步
3.A转发B的消息msg_b
1)在t_msg_info_A中添加这条元消息msg_a，type为2
2)更新t_user_info_A中Msg_count
3)在t_uer_msg_index_A中插入A发的这条消息的索引(A的编号和消息编号)
4)在t_msg_info_B中更新msg_b的Transferred_count和Transfer_count
5)在t_msg_msg_relation中添加User_a,msg_a与User_b，msg_b的转发关系，page_index为Transferred_count%page_count
4.A评论B的消息msg_b
1)在t_msg_info_A中添加这条元消息msg_a，type为1
2)更新t_user_info_A中Msg_count
3)在t_uer_msg_index_A中插入A发的这条消息的索引(A的编号和消息编号)
4)在t_msg_info_B中更新msg_b的Commented_count和Comment_count
5)在t_msg_msg_relation中添加User_a,msg_a与User_b，msg_b的评论关系，page_index为Commented_count%page_count
5.A删除消息msg_a
1)删除t_msg_info中的元数据msg_a
2)删除t_uer_msg_index_A中的User_a，msg_a行记录
3)备注：如果A的msg_a被别人评论或者引用，那么在对方查看评论或者转发的时候会提示“原消息已被作者删除”
6.A删除转发消息msg_a
1)删除t_msg_info_A中的元数据msg_a
2)删除t_uer_msg_index_A中的User_a，msg_a行记录
3)在t_msg_msg_relation_A表中找到msg_a的源消息，即B的msg_b
4)删除t_msg_msg_relation_A中user_a，msg_a和user_b，msg_b的转发关系
5)更新t_msg_info_B中msg_b记录的Transfer_count，减1
7.A删除评论消息msg_a
1)删除t_msg_info_A中的元数据msg_a
2)删除t_uer_msg_index_A中的User_a，msg_a行记录
3)在t_msg_msg_relation_A表中找到msg_a的源消息，即B的msg_b
4)删除t_msg_msg_relation_A中user_a，msg_a和user_b，msg_b的评论关系
5)更新t_msg_info_B中msg_b记录的Commecnt_count，减1
8.A拉取全部消息
1)从t_uer_msg_index_A中拉取Author_id，Msg_id，Time_t索引，并以Time_t排序
2)通过页码和每页count控制返回结果数量，这样避免了server io 压力冲击
5月25日更新：
1)条件允许的话，所有的index表可以放到内存中，全部cache，而元数据直接ssd，这样读速度会提高很多，当然也要做好热备
2)t_user_relation表最好做合并存储
5月27日更新：
1)在第二步原创发消息要通知给粉丝，这时如果是明星，那么推送的数量可能数百万，新浪采取的做法是对这数百万粉丝进行区别对待，按照活跃度划分为几个层级，每个层级有一个推送时效限定，这样可以做到最想看到这个信息的人能够最及时的看到明星动态
2)用硬件来提升速度，将所有index表放在memory上，元数据放在ssd上，数据可以现在这两层上做处理，并定时持久化到mysql中
3)提供批量处理接口，比如拉取最新更新索引
4)在一定限度上容忍不一样，但要实现最终一致性
6月1日更新：
6月30日更新：
在新浪微博中，评论和转发都与原创消息是一样的独立记录，只不过多了一条消息关系记录，在展现的时候除了要展现自己添加的转发内容或评论内容之外，还需要将最原始的那条目标消息取出来。
12月8日更新：
消息与消息关系表(t_msg_msg_relation)的备注中，应该是以Referenced_id取模分裂
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------28楼 Heasily 2013-04-02 02:01发表 [回复]
博主，我有个疑问：
比如我关注了A和B，比如 有1000000个用户，分页显示为10个为一页，如何执行一次查询 我关注的A或者B是否在这10个用户当中。前提是不能全表扫描。。。。27楼 banfuping 2013-01-05 16:34发表 [回复]
你好，查找关注我的人的列表该怎么查？26楼 cut21 2012-08-18 22:23发表 [回复]
你好！有个问题，A关注B应该不仅仅是在用户关系表中新增两条关系数据，还需要在用户消息索引表(t_uer_msg_index)里添加n条(假设B有发了n条微博)记录吧。这样设计用户消息索引表(t_uer_msg_index)压力是否太大，如果将这个表全部缓存的话怎么保持这个数据是新鲜的，能描述一下整个业务流程吗？望赐教，谢谢25楼 kclawfk 2012-08-08 16:48发表 [回复]
感谢分享，逻辑清晰容易理解~24楼 zhoujianghai 2012-07-29 16:46发表 [回复]
微博uid的生成策略是什么呢Re: cleanfield 2012-08-07 15:15发表 [回复]
回复zhoujianghai：像这个量级的用户uid分配肯定是有一个全局的服务，一次注册在池中分配一个uid出来，在池子容量少于一个阈值时补充生成uid23楼 ivawzh 2012-06-03 10:39发表 [回复]
高手. 有空的话顺便猜想一下facebook的表好吗? 会对我们的认识帮助很大.22楼
怎么以User_id取模分表？取模分表又是什么意思？ 希望高手指点Re: cleanfield 2012-04-18 17:25发表 [回复]回复zhushangweinihao：通过取模来散列，hash，类似
uid % mod21楼 zw19900913 2012-04-12 15:33发表 [回复]
看了楼主文章很受启发，但是还是因为初学还是有些不理解。若是用hibernate做类之间的联系，那么是不是就可以不用设置这些联合主键，而使用实体关联关系映射的方式呢？若是的话，应该怎么设计？Re: cleanfield 2012-04-12 22:25发表 [回复]回复zw19900913：呵呵，不好意思，java这一套我不懂，我没有用过中间件，我的经验都是直接操作mysql api20楼 滴水成海 2012-04-06 17:31发表 [回复]
楼主给某个人的私信的业务逻辑怎么实现？Re: cleanfield 2012-04-07 10:49发表 [回复]回复liu_xing_hui：私信可以跟微博一样，也可以不一样，不过总体来说字段信息都差不多， id, content，uid, from_uid，create_time. 一条私信也就是这样一条记录，此处uid是接收方的uid，且以此取模分表。19楼 azmwz 2012-03-10 18:20发表 [回复]
博主，你好。按照这个设计，我如何区分已读评论和未读评论呢？Re: cleanfield 2012-03-11 12:31发表 [回复]回复azmwz：你好，评论没有已读和未读的概念吧，一般来说在有新消息来的时候都是未读的，需要更新一个未读条数的字段，用户打开消息列表一次，所有的未读都标志为已读，本文只是主要的数据表，生产环境当然只有这些表还不够，我只是抛砖引玉，大家可以根据实际需求完善。18楼 amuropikin 2012-03-05 12:53发表 [回复]
楼主你好，作为菜鸟我点不懂：消息元数据中包含转发的内容，t_msg_msg_relation 以用户id 进行sharding么？这样单独查看一个用户发的微博，他转发的消息应该是散列分布的，这条元数据该怎么有效获得呢？Re: cleanfield 2012-03-05 14:06发表 [回复]回复amuropikin：所有的都是以用户id来sharding的，这样跟每个用户相关的消息肯定是聚合的Re: amuropikin 2012-03-16 13:22发表 [回复]回复cleanfield：还有个问题，用户删除了消息时怎么处理呢，这条消息的索引推送给许多用户，这时这条索引等于是垃圾信息，在用户的收件箱里占着位置应该会影响分页和排序吧？难道是在查询的时候删除么，不会影响效率么。。。感谢楼主解答：)Re: cleanfield 2012-03-19 01:03发表 [回复]回复amuropikin：首先从产品层面来说，主动删除的微博数占总数的多少，有敏感话题被删除的微博占总数的多少，这两者的和能够占多少比例？答案肯定是很少很少，虽然我不清楚新浪的统计数据。再从数据处理方面来说，作为以时间抽这一维度来存储数据的微博来说，追加方式的写效率是最高的，在一个以前时间点上的数据块中做删除操作的代价比较高，删除之后这块空间也是不能利用的，不然这些空间上的随即写是低效的，管理这些node也不方便。现在新浪微博被删除的微博也会放在正常的列表当中，排序分页都会考虑，这样效率高而不是效率低17楼 woxiangxin 2012-03-04 15:16发表 [回复]
楼主好，关于用户消息索引表的用法，想到个问题，请教一下
现在想到的几种方式是，1：在展示首页的时候先从索引表中分页拉出msg_id，然后再到消息元数据表里逐条的去select，比如每页20条就select 20次
2：因为我想t_uer_msg_index中的数据不会长久的存在，就想着在t_uer_msg_index中把消息的内容等需要展示的信息也都放进去，只从t_uer_msg_index中取数据，实现首页的拉取
3：把t_uer_msg_index都放到缓存，再按照1的方式去读取消息元数据，2就不需要去读元数据了
现在的问题是，类似需要用到索引表的情况，按照1的这种方式先取索引，再逐条select是不是合理，除了这些还有没有其他的方式
望赐教Re: cleanfield 2012-03-04 16:03发表 [回复]回复woxiangxin：其实本文的实现完全是基于mysql，所以对于访问量大的时候肯定扛不住，升级方式就是采用前端cache+后端db，每条消息都可以缓存在cache中，有一个有效期，这个需要通过线上环境得出一个兼顾一个存取时间和cache空间的最佳值。在cache中的mget可以实现一次读取多条信息，比如一页20条，那可以一次mget操作就全部拉取出来。你说的那个在用户消息索引表中多放一些信息，我觉得这是可以的，比如把消息内容放进来都可以。但是这条信息并不是要显示的全部信息，关于这条信息的转发次数，评论次数等等的信息还需要再一次的拉取。有一点，信息要区分动态信息还是静态信息，比如微博内容就是静态信息，这个是可以缓存在索引表中，也可以只放在信息元数据中，像评论数和转发数这些是动态信息，用户消息索引表中存的是静态信息，只做排序用，后续每条消息的详情需要从元数据表中拉取。
其实我这篇也只是一个mysql基础实现，只是抛砖引玉，当前的新浪微薄和腾讯微博肯定架构要复杂的多，redis+mysql，而且还有很多种缓存策略，按照时间线来划分访问频率，每个阶段有对应的存储策略和访问控制，我们当前的feed系统采用的是 redis + mysql，效果挺好。16楼 vivaxiaohua 2012-02-29 16:07发表 [回复]
中规中矩的设计，基本可以做出一个demo了15楼 woxiangxin 2012-02-29 14:38发表 [回复]请问，如果A、B两个用户的hash在一张表
那A关注B，在用户关系表中保存
A--B--1
B--A--0
如果B又关注了A，成为相互关注的关系，应该怎么保存呢Re: cleanfield 2012-02-29 16:46发表 [回复]回复woxiangxin：其实最好是分开用户关系，设置两张表：粉丝表和关注对象表，不过还是需要两种flag：0(关注或者是被关注)
1 (互粉)
我们现在的生产系统就是这样的Re: MyOracleX 2012-06-07 23:47发表 [回复]
回复cleanfield：你好！为什么关系不能设成一张表？比如说
A--B
A--C
这样A的粉丝有B、C
B--A
C--A
B的粉丝有A，C的粉丝也有A。
请楼主解答一下Re: cleanfield 2012-02-29 16:43发表 [回复]回复woxiangxin：呵呵，这样会有另两条记录：
B A 1
A B 0
不过这样的记录并不能插入(因为A-B或者B-A的联合主键重复了)，解决办法就是如果发现A-B是互粉的，那么就将关系标识设置成2，即修改记录为:
A B 2
B A 2
在查找自己的粉丝的时候，需要找 flag是0或者2；
在查找自己的关注对象的时候，需要找 flag是1或者2；14楼 cfm1989 2012-02-28 10:36发表 [回复]
请问一下，“@人"的功能怎么实现，还要建什么表呢？Re: cleanfield 2012-02-28 11:37发表 [回复]回复cfm1989：@berniewu，首先一点很明确，在新浪微薄中berniewu账号只有一个，所以新浪微博的后台肯定有一个berniewu1852824502这个的双向映射，而且肯定是在cache中；一篇微博中所有涉及到的@人，都会在后台映射成一个id，就相当于转发或者是评论，不用建新表，当前的这些表完全满足需求Re: cfm1989 2012-02-28 16:00发表 [回复]回复cleanfield：噢，其实我就想做一个作业而已。我想问当我@了你 后，你是怎么获取到这个消息的呢？Re: cleanfield 2012-02-28 18:00发表 [回复]回复cfm1989：A@B之后，就相当于B被动地关注了A(虽然可能并不存在这样的关注关系，但是在A发@B的这条微博的时候，这种“被关注”关系是暂时存在的)，这条微博(编号msg_1)会发送给所有关注A的人，包括“暂时关注“A的B，也就是说在消息索引表中会存在一条记录： B_id(接收者) + A_id(发送者) + msg_1(消息索引)。此时B登录当然可以看到这条信息Re: woxiangxin 2012-02-29 14:16发表 [回复]回复cleanfield：有一点不太明白，我理解的用户消息索引表的内容应该是不会无限增长下去的，会按照一定的阀值清理，或者在取消了关注后也同时清理，否则，这些消息推来推去的，即使分表的话，数据量也太大了。
但此时，如果用户想看“提到我的”列表，但那条提到我的消息已经被清了，就查不到了，所以是不是还是需要一张保存提到的表呢。Re: cfm1989 2012-03-01 13:23发表 [回复]回复woxiangxin：现在我要实现查看"我收到的评论"列表，还有“@我的”列表，A评论了B的微博，A@了B，B可以查看到A的评论信息和A@B这条微博也是通过t_user_msg_index索引表，那我是不是要添加一个字段type来表示B看到的这条到底是“评论”还是“@我”的，或者还是拉取"我的首页"全部信息的13楼 tengyue5i5j 2012-02-21 18:59发表 [回复]
用户消息索引表(t_uer_msg_index)中主键对吗？ 难道一个用户不可以重复发同一个消息？Re: cleanfield 2012-02-22 17:09发表 [回复]回复tengyue5i5j：tengyue5i5j，这个问题你可以在微博上实验12楼 zengjd 2012-02-14 15:13发表 [回复]
这篇文中提到的“用户消息索引表(t_uer_msg_index)”我不太理解。
为什么要需要这样一个表呢？
按我有限的知识理解，通过“用户之间关系表(t_user_relation)”和“消息元数据表(t_msg_info)”也可以得到所有被关注者的消息。
而且还省去了插入删除t_uer_msg_index表达麻烦。
请大虾指点！Re: cleanfield 2012-02-16 19:06发表 [回复]回复zengjd：这个索引表只是为了在汇集好友的微博信息时浏览排序方便，只需要4个字段的索引就可以做到，不必存储全量信息；当然现在有一种观点是后台尽量完成所有事情，前端只负责显示，这样的话这种索引的信息会显得单薄，需要冗余多放一些信息在cache中。Re: zengjd 2012-02-17 14:31发表 [回复]回复
还是有点不明白，为了“汇集好友的微博信息时浏览排序方便”，也完全可以通过t_user_relation和t_msg_info来完成啊，为什么需要t_uer_msg_index呢？
：Re: cleanfield 2012-02-17 23:05发表 [回复]回复zengjd：zengjd，你忽略了一个问题，对于首页的信息，要做到快速拉取，如果你通过relation表先找出好友，然后再去好友中找他们发过的消息，后续还要进行统一的排序，这是一个相当费时非空间的过程。而t_uer_msg_index表正是push模式的核心，不用经过process，直接按照time_t排序就可以拿到消息列表。对于首页，我们坚持的第一原则就是快速显示内容。对于pull的模式，我们采用的就是redis缓存+mysql落地的架构，在拉取首页信息的时候process出消息列表，每个人发布的最新N条信息是放在cache中，A查看首页时，就是先从cache中找出所有好友的消息列表cache节点，然后内存排序，生成一个有ttl的列表节点。说的有点多了，你重点可以理解下前面的push模式Re: MyOracleX 2012-06-07 23:51发表 [回复]回复cleanfield：根据这样的设计发现每次插入时要更新好多表，这样会不会也出现问题Re: zengjd 2012-02-21 16:55发表 [回复]回复cleanfield：非常感谢你的耐心回复，我明白了:
如果通过t_user_relation的Follow_id关联t_msg_info表，需要全表扫描。
而通过t_uer_msg_index关联t_msg_info，则扫描t_msg_info表的前N条记录(N为一页显示消息的条数)11楼 woxiangxin 2011-12-06 11:07发表 [回复]楼主好，请问，消息关系表的好处主要是什么呢，是否可以在消息元数据表里增加类似的字段(比如，被引用的消息编号，消息发布者编号等)满足同样的功能Re: cleanfield 2011-12-08 10:07发表 [回复]回复woxiangxin：消息关系表的好处就是利用这张表可以很快找到消息A的所有的评论和转发，因为A的所有评论和转发都是放在t_msg_msg_relation_xx(xx为A_id取模后的值)；在消息元数据中加入被引用的消息编号，消息发布者编号等满足不了要求，因为这个表是以uid取模分裂的，也就是说消息A的所有评论和转发可能分布在所有的消息表中，要实现拉取消息A的所有评论和转发需要全库全表扫描，这是一定不能容忍的Re: woxiangxin 2011-12-08 23:27发表 [回复]回复cleanfield：非常感谢10楼 eewcee 2011-12-04 22:47发表 [回复]
博主你好，这有个问题：如果不是一开始就关注的用户，在用户发表微博以后再关注用户，那么“我的首页”将无法显示用户在被关注之前发表的微博，事实上并非如此。是不是应该考虑下这种情况呢Re: cleanfield 2011-12-08 10:18发表 [回复]回复eewcee：其实你说的这个问题很好解决，我们的feed系统也是这样设计的：每个人的feed信息是在redis中有一个缓存节点，其中放用户最近发表的N条feed(这个N是用户体验的一个衡量值)，比如A在redis中有20条缓存feed，这时B关注A，然后A又发表了10条feed，那么在B的首页拉取时就有可能最多看到A的30条feed，当然B的首页的显示结果是他所有关注对象的redis cache结果全部按时间优先排列的。如果B想看A更早的feed，就只有去A的消息元数据中查找了，这并不在cache中Re: woxiangxin 2011-12-06 11:11发表 [回复]回复eewcee：我想是不是可以在关注的时候按照一定的规则，将被关注用户一定时间内发布的微博放到当前用户的用户微博索引表中，这样在首页抽取的时候就可以看到了Re: eewcee 2011-12-06 18:00发表 [回复]回复woxiangxin：嗯，这样是可以实现，仔细看了下微博，像新浪微博个人首页一共分页也就90页，如果使用消息索引表的话估计还得定期清理无用数据了，还有挺多要考虑的9楼 Elvis_wangyi 2011-11-20 13:39发表 [回复]
AB相互关注，并且AB在同一个表中，那么user_relation中的两个联合主键是不是要改成三个字段都要是联合主键Re: cleanfield 2011-11-23 13:05发表 [回复]回复Elvis_wangyi：在数据库中 A-B的键值与B-A的键值是不同的8楼 lawliet_tang 2011-10-11 16:01发表 [回复]
通过页码和每页count控制返回结果数量，这样避免了server io 压力冲击，还有t_msg_msg_relation表的page_index字段是具体如何利用的？我这点我不太理解Re: cleanfield 2011-10-12 08:48发表 [回复]回复lawliet_tang：回复lawliet_tang：1.最基本的分页拉取方式就是page_number+count，在sql中就是select ... from xxx order by xx_col limit base_num, offset_count, 这里base_num = (page_number - 1)* count_per_page。
2.page_index在拉取评论的时候是作为where子句的，而且这里可以当作索引，在拉取某一页的评论时会快很多7楼 zhangjihao 2011-08-12 11:06发表 [回复]
弱弱地问一下，User_id是如何编码的？
自增长？
时间？Re: cleanfield 2011-12-09 00:44发表 [回复]回复zhangjihao：uid是另一个帐号系统维护的，一般都是自增的6楼 shanteng 2011-06-30 14:19发表 [回复]
明白了，感谢。5楼 shanteng 2011-06-29 23:15发表 [回复]3.A转发B的消息msg_b ...
4)在t_msg_info_B中更新msg_b的...
t_msg_info_B和t_msg_info_A是两个表么？原创、转发、评论三种消息都存在t_msg_info_A中，那t_msg_info_B存的是什么呢？不甚理解[e08]Re: cleanfield 2011-06-30 09:36发表 [回复]回复 shanteng：在新浪微博中，原创，转发，评论其实都是独立的一条消息记录，只不过转发和评论在基础元数据的记录中会有type标识，同时在消息的关系表中也有对应的一条记录；在展现的时候，如果是转发或者评论，就会在展现转发和评论新增内容的同时将最原始的消息本身也展现出来Re: cleanfield 2011-06-30 09:32发表 [回复]回复 shanteng：t_msg_info_A和t_msg_info_B是A和B通过hash后所在的表，当然也能是同一张表(A和Bhash落在了同一张表中)4楼 jianghuili_hao 2011-05-23 18:27发表 [回复]
[e01]3楼 cleanfield 2011-05-07 07:52发表 [回复]当然更高级的就是采用专门为海量数据设计的nosql2楼 cleanfield 2011-05-07 07:52发表 [回复]一般的策略包括sharding，flashcache，ssd，优先硬件解决，遭遇瓶颈继续软件，就是这样一个迭代的过程。而过程中的每一步，都是有一个区别对待的策略，即压力大访问频繁的表sharding粒度更大，或者说给予特别优待，包括处理优先级，分配的资源性能等。1楼 编码人V1 2011-05-06 23:27发表 [回复]
如果A关注B，添加了两条记录，会不会显得数据冗余呢？这样做有什么好处吗？是不是因为分表的缘故容易查询？加入不分表的话，是否有这样的必要？Re: cleanfield 2011-05-07 00:27发表 [回复]回复 freemancqcsdn：是有分表的原因，为了更好的sharding，而且使得A与B的查询互不影响，故而做这样的冗余也是很有必要的。考虑到数据量级的逐渐增大，分表又变得非常必要，使得这样的冗余对于查询效率的提高是很有帮助的。我个人看法是，在海量数据面前，查询效率是首要考虑 的因素回复 freemancqcsdn：为了更好的sharding，A与B的查询互不影响，故而做这样的冗余也是很有必要的。考虑到数据量级的逐渐增大，分表又变得非常必要，使得这样的冗余对于查询效率的提高是很有帮助的。在海量数据面前，查询效率是首要考虑 的因素Re: 编码人V1 2011-05-07 08:40发表 [回复]回复 cleanfield：
多谢，明白了。回复freemancqcsdn：不客气，欢迎多交流
----------
http://blog.csdn.net/cleanfield/article/details/6339428这篇微博中分析了新浪微博，腾讯微博数据库主表结构。这篇文中提到的“用户消息索引表(t_uer_msg_index)”我不太理解。为什么要需要这样一个表呢？按我有限的知识理解，通过“用户之间关系表(t_user_relation)”和“消息元数据表(t_msg_info)”也可以得到所有被关注者的消息。而且还省去了插入删除t_uer_msg_index表达麻烦。
--------
我理解：如果通过t_user_relation的Follow_id关联t_msg_info表，需要全表扫描。而通过t_uer_msg_index关联t_msg_info，则扫描t_msg_info表的前N条记录(N为一页显示消息的条数)
用户消息索引表(t_uer_msg_index)这个表的主键貌似不对吧？ 难道用户不可以重复发同一个消息？
csdxqzp 写道
我问你 单表扫描 和 索引扫描 哪个来的直接一些
这个例子里面是怎么体现单表扫描和索引扫描的？就我帖子中的疑问。能不能具体讲讲。谢谢！
