有关大数据量统计数据展示查询的探讨

最近接了一个遗留的系统，后台有一张千万级的单表做为基础的数据源，还有一些扩展表用于记录业务的详细信息，在数据源表的关键字段上都建立了索引，但是最近由于业务量的增加，对于该表的查询和统计越来越频繁，有时候一个大的关联SQL会执行好十几分钟，CPU的占用率也非常高，客户很不满意。

 

 

解决方案:

 

考虑到前台的统计查询需求是延期的，就是今天查询昨天以前的数据，这个月查询上个月以前的数据，基本没有实时性，所以感觉后台的关联实时查询不是很必要，就用了所见即所得的方式来改造。

 

如下：

1：

根据前台的业务展示设计一张一一对应的单表，然后加上足够的扩展字段方便以后需求的变更，具体的必须字段可更具具体情况来定。

 

2：

后台跑定时程序，跑统计SQL将结果放入展示单表。

 

就这么简单，这样的好处是统计的过程是可控的，不会让客户来直接操作，客户查询的速度明显提高，因为现在一个业务需求查询只针对一张单表，不涉及到关联其他的表。缺点是实时性不好。

 

 

从上面的解决方案也可以看出前期的设计非常重要，如果后台的表结构不合理，会对日后的业务查询统计带来不可知的复杂度.

千万级的单表应该考虑分库分表，搞个历史库啥的

因为该表涉及到其他系统的dblink，如果单方面改分表的话会影响到其他的系统，这些都是之前设计没考虑的问题，现在开始修修补补了，郁闷.......

恩，我们的系统也是用分表来减压

大数据量通常考虑使用数据库提供的特有功能。例如oracle的话，可以考虑用物化视图、快照，这样甚至在一定条件下即使实时性也可以没问题；或者如果查询和时间区间相关性较强，可以考虑用partition分区技术将数据切片以降低查询cost。

1、使用Oracle，MySQL的分区表功能。
2、如果是Oracle可以使用大内存进行缓存（推荐用64位系统），我们就这么做。
3、报表类数据采用定时统计数据存储在汇总数据表中（就是楼主目前采用的方法）。

1.分库分表，不过有局限性，分库分表后的sql有一定的限制。
2.根据具体场景加缓存。

1.ali的广告满天飞
2.看看javaeye的博客排名，应该也是调度任务跑出来的

哈哈 一看上面的招聘要求就是ali的 嘿嘿

建议je的管理员出来删广告，还有，那个发广告的人把自己头像的连接直接转到了je的主页，不知掉怎么设置的，难道是和je串通的吗??