我做了一个文章发布的功能。待选用的两种方案:有一个主表存放文档的主要信息,表结构如下:表main: 
contentid    文档ID 
typeid       所属栏目    
title        标题   
thumb        形象图  
keywords     关键字   
description  描述      
url          转向
listorder    排序  
status       状态 
userid       录入者ID   
username     录入者姓名  
inputtime    录入时间
updatetime   更新时间 
...           等
             其中检索一般用typeid做为标准配合其他限制,比如userid、inputtime。第一种方案:直接查询main表。 如“select * from main where typeid=4 and userid>4”第二种方案:再创建一个微表,微表仅存放常用的会检索的字段。表机构如下:表tiny:
contentid  文档ID    
typeid     所属栏目          
userid     录入者ID        
inputtime  录入时间    
               
这样查询的时候,就查询微表,如“select * from tiny where typeid=4 and userid>4” 
获得符合条件的 contentid  记为ids,
使用  select * from main where contentid in (ids) 查询主表获取信息。这两种方式哪种效果会更好些呢?这样的设计可能不可以一概而论,牵涉到表结构的设计,已经数据量的大小。我假设一种情况,
contentid、typeid、userid、inputtime  这些会在检索时候用的字段都索引了,数据量就按照很多处理,比如100W的数据。这样的话,哪种方案会好些?又或您有更好的方案,不吝赐教

解决方案 »

  1.   

    不考虑数据冗余的话,其实一张表查询更快,你只要对typeid字段做索引就好了多字段的索引对于提高查询效率其实没有太大的帮助,因为多字段意味着重复值少,hash表就比较分散了。最多是typeid和userid做联合索引,如果userid的查询情况比较多的话。
      

  2.   

    当然是第一种方案快,索引只会针对特定的字段,且直接指向了数据地址。当然如果你要求更极速的速度和更多的检索内容,建议使用sphinx。
      

  3.   

    一般情况下,第一中要好点。
    昨天百度的人发了一系列关于mysql分区的帖子,你可以看下:
    http://topic.csdn.net/u/20100811/17/86c0a1ce-ee05-448e-9ba1-49b293cba3aa.html
    http://topic.csdn.net/u/20100811/17/ae9f2d7f-4510-417a-9090-a2ddc8049c22.html
    http://topic.csdn.net/u/20100811/17/f806026e-9df7-49df-8272-6e0c948c2adc.html
    http://topic.csdn.net/u/20100811/17/77a2d9ad-a8a8-4f42-834f-1c3c0dfb737e.html
    http://topic.csdn.net/u/20100811/18/388d60ff-0632-4b0e-b280-edd9d7fc689f.html
    http://topic.csdn.net/u/20100811/18/cfa3e3ad-8b7a-41aa-9f29-83ee6f5e779f.html希望对你有帮助。
      

  4.   

    看了你的设计,如果对typeid建索引,在大数量下估计都不会使用索引了,原因就是你这个TYPEID估计应该会有很多重复的值,超过一定量MYSQL也就不会走索引了,对录入者ID与录入时间进行索引,倒可以考虑,对于LZ这种表,最好还是拆分成两张表比较好,至于后面用IN来查询一个记录集,我相信还是可以接受的,用EXPLAIN检查一下就会知道其实他的TYPE还是可以达到RANGE级别的,所以还可以接受
      

  5.   

    第二种相当于自己维护一份索引表,你要考虑到主表记录的增删都是要相应更新你那个tiny表的。至于使用in(主键) 会比使用 (typeid,userid)联合索引效率高多少,需要LZ进一步测试才能判断,不过100W数据,感觉联合索引(typeid,userid)就够了,也要看实际数据的分布情况,分区,分表都有可能。
      

  6.   

    建议楼主还是用第一种吧,原因:通用性强,可以适当的进行sql优化