大表分表的问题

公司在做一个山寨的百度统计，对本公司网站的用户进行行为分析。在网站的页面嵌套了脚本采集一些日志数据，然后通过SQLLDR把日志导入到数据库里，再对这些日志进行分析生成一些报表。最细颗粒度是每小时导一次数据，统计一次。每天还需要做一次统计，且也是直接扫描基表的。这里需要统计的纬度很多，算了一下，做完所有的统计，需要对基表做14-18个全表扫描，感觉性能很差。后来对日志基表做了按小时的时间表范围分区，每小时的统计的速度有了质的飞跃。但每天的统计还是比较差，尤其当数据量上升到6000W时，惨不忍睹。

因为统计扫描基表时是且全表扫描的。所以优化的一个思路是减少基表的BLOCK。一个方向是去丢一些无用的字段，还有一个方向是考虑分表。

对于分表的一些基本思想：分离较长字段，逻辑性关联强且字段短的可放同一表，考虑到表关联会带来一定的性能下降，所以公共纬度的字段会在分表里冗余。

-------------------------------------------------------------------

另外也在网上找了一些分表的设计思想：

个人看法： 
使用超大表的特点： 
1、查询语句可以一次性准确扫描到所需的数据块，从磁盘上读取的数据 
      块应该很少； 
2、查询语句可以简化，且方便优化； 
3、根据数据量多少，可以按年份进行分区，或者考虑按季、月等进行分区； 
4、管理方便。 
使用小表的特点： 
1、因为查询数据时可能涉及到读取所有的表，所以不可避免发生表联接， 
      表联接造成读取数据块的数量可能大于同样数据的超大表，所以从磁盘 
      上读取的数据块应该很多，这样会引起大量的I/O； 
2、查询语句可能很复杂，所以会给优化增加成本，降低效率； 
3、多表管理较复杂。 
所以我认为可以考虑在超大表上建立分区，根据可能的数据量按时间进行 
表分区，然后建立合理的索引，这样效率可能会高一些。 
当然所有的合理选择都是以完善的测试为前提，所以建议楼主将所有可能 
引起的操作列出来，然后再进行测试，比较，最后再考虑使用哪种方法。 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/540427/viewspace-680396/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/540427/viewspace-680396/