现在大家都知道,邮箱里面单个用户的收件记录都可以保存很多,目前我也正碰到一个类似存放如此记录需求的项目:有n多个用户,每个用户有m条记录,假如是1000万个用户,每个用户有50万条记录,而此表要时刻写记录及查询记录。不知道这样的表怎样设计才算合理,才能满足以上需求。
请各位帮忙指点分析下。
先谢谢了!

解决方案 »

  1.   

    插入没有什么性能影响。查询看你需要哪些查询功能了。列几点建议供参考:
    1.如1楼所说,建立分区表,最好各分区表所在的表空间在不同磁盘上
    2.在查询条件的常用列上建立索引,由于经常插入只能建立普通索引(B*树索引).如你所述,用户表是比较大的,所以如果它的索引能充分利用,性能不会太大影响。
    3.注意你的SQL语句,要能真正利用起索引。
    4.适当扩大SGA,以使内存中能存储更多的记录
    5.如果机器上有多个cpu,可采用并行查询,这对查询性能有比较大的提高。其他的楼下高手补充。
      

  2.   

    A->B->C
    B->C
    C--DATAA--DATA
    B--DATA
    C--DATA
      

  3.   

    bjt_ 
    bjt 
    等 级:
     发表于:2007-11-15 22:41:063楼 得分:0 
    1   分区表用的不好,不如不用 2   索引才是解决大数据量的方法,一定要用索引 3   如果实在性能有问题,可考虑手工拆分成多张表进行处理 
     
    ========================================================
    同意,分区表假如你对数据理解的不是很深,或则写程序的人对于这块不是很理解的情况下还是不要用了可以根据用户类型或注册地区等能区分用户群体,而且能保证每个用户群体数量基本一致,来分别建立表格
    每张表分别建立表空间,每个表空间建立多个数据文件,建议数据文件基本保持在2-4个G左右,不要太大了
    各表最好分别建立在多个逻辑分区上估算一下,大概数据量更新在30%以上的时候一定要重建一次索引,确保索引的有效性
    =======================
    在对你自己的数据进行深刻分析后,最终的建议还是建议你用分区表
    分区表的应用,跟应用程序中的sql写的好与坏有很大的分别的
    你管数据库的话,一定要跟踪优化好另外,建表的时候,一定要考虑大数据量情况下索引建立的效果,对于有些字段的设置,会影响到索引效果的话,该合并的合并,该拆分的就要拆分
    不要太迁就写程序的方便
    毕竟对于大数量级的应用,效率才是第一的参数表的应用,在有可能的情况下也要少用,尽量存储真实值,毕竟相对于提高效率来说,存储成本现在基本是可以忽略不计的。
      

  4.   

    若使用分区表还需要注意分区索引(local index)的使用。
      

  5.   

    建议按用户性质或类型分成N个表,然后建索引A-> B-> C 
    B-> C 
    C--DATA A--DATA 
    B--DATA 
    C--DATA