解决方案 »

  1.   

    待高手解答。。学习一下。。
    B.TYPE加索引肯定没啥效果。
    两个表都5000万的数据量不分区的话肯定够呛
      

  2.   

     我能想到的也不多,表a和表b都建立分区,表b的TYPE列最好建立索引
      

  3.   

    建什么分区呢?hash分区?type字段建一般的索引还是位图索引?
      

  4.   

    请问a,b,c三个字段存的都是什么类型的数据
    楼上说的应该是散列分区,范围分区等吧
      

  5.   

    建什么分区呢?hash分区?type字段建一般的索引还是位图索引?
    我的意思是,既然数据量有这么大,肯定不是一次性插入的。可以依据插入的时间,按照时间建立对应的时间分区,我就是这么理解的。
      

  6.   

    个人建议LZ可以考虑在FROM子句做调整,尽量缩小数据集大小试试,另外要优化,最后给出执行计划。例如:
    SELECT A.XX FROM (select a,b,c from TABLE1) A, (select a,b,c from TABLE2 where type in (1,2,3)) B
    WHERE A.A=B.A
    AND A.B=B.B
    AND A.C=B.C
      

  7.   

    整个语句就是这个
    SELECT A.XX FROM TABLE1 A, TABLE2 B
    WHERE A.A=B.A
    AND A.B=B.B
    AND A.C=B.C
    AND B.TYPE IN (1,2,3)B.TYPE 一共1,2,3,4 这个条件只排除掉1/4也就是还是有3/4的数据。另外设置数据库参数其他方面有没有可优化的地方,只要速度上去就可以了
      

  8.   

    在两表的abc三个列上都建联合索引,不知效果如何。
      

  9.   

    整个语句就是这个
    SELECT A.XX FROM TABLE1 A, TABLE2 B
    WHERE A.A=B.A
    AND A.B=B.B
    AND A.C=B.C
    AND B.TYPE IN (1,2,3)B.TYPE 一共1,2,3,4 这个条件只排除掉1/4也就是还是有3/4的数据。另外设置数据库参数其他方面有没有可优化的地方,只要速度上去就可以了这就是整个语句的话,就没什么好优化的了。我是不太清楚,一个查询结果有几千万条记录,那么这个查询的意义何在
      

  10.   

    因为几乎全表都要输出,索引什么的,就压根没有必要了。准备好足够大的内存和temp空间,进行hash join,单单是查询结果传到应用端就要耗茫茫多的网络流量,快不了的
      

  11.   

    SELECT A.XX FROM TABLE1 A, TABLE2 B WHERE A.A=B.A AND A.B=B.B AND A.C=B.C AND B.TYPE IN (1,2,3)a,b,c建立索引,b表的type建立列表分区试试
      

  12.   

    7楼对这个背景下 这两个表的join 如果可以 就hash  其次 sort merge   
    即便连接的列有索引 也没有效果  
    全表扫描已经无法避免  只能  where 后的非join条件上 优化   尽量减少结果集对了  大表关注下水位线问题
      

  13.   

    那hash join是oracle优化器自动选择的吗,增加内存是增加pga部分的内存吗?
    这个查询是为了生成数据插入到一张表中。etl中的其中一步。
    有规定是需要在规定的时间内完成的。如果确实需要加大内存或者调增pga中的参数可以实现,那也是可以的。
      

  14.   

    另外这两张表用这三个字段做hash分区有效果没?
      

  15.   

    没有效果。hash连接和hash分区没什么关系
    如果结果集就有这么大,该查询没有优化余地。倒是可以试着分几批来插入
      

  16.   

    如果这张表只是用来查询的话,为什么type不建位图索引?
      

  17.   

    个人觉得, 先用type滤出一部分的数据(这里可用位图索引加速), 即使是1000万 也是少了4000万,然后用滤除来的这部分做驱动表去关联另外一张大表,在连接条件上建索引,用索引去fetch 这张大表。 这样总的数据量会少很多。 
      

  18.   

    如果不嫌麻烦,可以试着把表试着分割为多个表,每个表记录给定几百万,话说楼主几千万的数据A B C一起没有重复的么?这种查询在索引或者分区上基本没什么能优化的地方,就像版主说的,在实际的查询中按where条件的筛选去尽量减少发生表关联的数据量,分割表也是这一思想。
    其实也不用做这个中间表吧!你可以把一步分为三步去做,取第一个表符合它条件的记录,取第二个表符合它条件的记录,第三步看情况放到一起去关联。
      

  19.   

    那hash join是oracle优化器自动选择的吗,增加内存是增加pga部分的内存吗?
    这个查询是为了生成数据插入到一张表中。etl中的其中一步。
    有规定是需要在规定的时间内完成的。如果确实需要加大内存或者调增pga中的参数可以实现,那也是可以的。你又不需要排序,加大PGA 做什么。
      

  20.   

    那hash join是oracle优化器自动选择的吗,增加内存是增加pga部分的内存吗?
    这个查询是为了生成数据插入到一张表中。etl中的其中一步。
    有规定是需要在规定的时间内完成的。如果确实需要加大内存或者调增pga中的参数可以实现,那也是可以的。你又不需要排序,加大PGA 做什么。没看上面, hash join 是要耗内存的, 但是如果是对hash join 调, 这点内存加上 也是杯水车薪
      

  21.   

    这么简单的sql,貌似真没有什么优化的地方。几乎全表查询,索引什么的应该用不到,直接就是全表扫描。
    前两天看书,看到一个"并行执行",LZ可以试一下,不知道能不能快点。
    select /*+ parallel(t,4)*/ t.a from t