解决方案 »

  1.   

    根据你的sql逻辑,是全表筛选统计,走的是全表扫描,不能走索引,所以50万的数据慢是很正常的而且sql已经比较简洁,在怎么优化效果也不明显目前比较常用的优化方案:1.更改业务逻辑,也需求的允许的范围内,缩小统计范围,比如增加where条件,走索引把计算数据量缩小。
    比如银行的交易流水,一般查询有限制3个月范围内等等2.如果数据实时性要求不高,可以考虑夜间作业跑批出结果表,直接插结果表也可以提高速度。
    比如报表一般都是T+1
      

  2.   

    主键索引是会走的,走的是索引快速全扫描。如果没有走索引的话,可以使用hit语句强制走索引。我用100W的数据进行测试了一下,需要5秒钟。我觉得你应该使用10046事件看看时间到底花费在什么地方。如果group by 之后的结果很多,我个人认为时间大多花费在网络传输上,此时可以将行预取参数设置大一些。如果时间花费在oracle自身计算上面,可以采用3#的说法,建立一个物化视图。
      

  3.   

    你可以对索引进行压缩 试试
     alter index T_Pk rebuild compress 1
     
      

  4.   

    sql的where条件主要是下面的这句,由于每个月搜索的话数据量太大,我加个条件限制时间
    and p.pointid in (select distinct (a.pointid)
                           from zdt_bm_1312 a,
                                (select pointid,
                                        decode(max(zybm) - min(zybm), 0, 0, 1) as biaoma
                                   from zdt_bm_1312 where datatime >'2014-1-1 00:00:00' and datatime < '2014-1-2 00:00:00'
                                  group by pointid) b
                          where b.biaoma = 1
                            and a.pointid = b.pointid)
    能帮我看看这还能怎么优化吗,还有你说的夜间做结果表的话是这么做的?