一条SQL优化

anlinew

原帖由 tan9030 于 2008-3-4 16:36 发表
今天先到这里，忙一会儿哈

不试一下？等结果呢

anlinew

原帖由 anlinew 于 2008-3-4 15:32 发表

a 可以驱动d也可以反过来通过test_number被d驱动
a 还可以通过wl_key被b或者c驱动
a 也可以通过site_number被c驱动

从上面的测试来看 a  通过wl_key被b驱动效果是很好的

目前情况是：
RBO下为了照顾'TDB_JOB_TEST'能走上'PK_TDB_JOB_TEST' ，选择了

a 通过TEST_NUMBER 被d驱动


----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (UNIQUE)
   2    1     NESTED LOOPS
   3    2       NESTED LOOPS
   4    3         NESTED LOOPS
   5    4           TABLE ACCESS (BY INDEX ROWID) OF b
      7    4           TABLE ACCESS (BY INDEX ROWID) OF d
     9    3         TABLE ACCESS (BY INDEX ROWID) OF a
    11    2       TABLE ACCESS (BY INDEX ROWID) OF c

这还算清楚了吧

这里面想办法把a跟d换个位子就差不多了

[ 本帖最后由 anlinew 于 2008-3-4 16:43 编辑 ]

anlinew

以上是基于RBO的说法，CBO没这么土。。。。。

tan9030

原帖由 anlinew 于 2008-3-4 16:30 发表

按照这个走下去估计最终也就毫秒级
RBO真是土啊


这样试试：

TDB_JOB_TEST d,                    大小576m,  (JOB_KEY, TEST_NUMBER)
改成test_number,job_key试试

原来的index (JOB_KEY, TEST_NUMBER) ，不能被drop，于是我重新建立了一个(TEST_NUMBER,JOB_KEY)
CREATE UNIQUE INDEX PK_TDB_JOB_TEST_1 ON TDB_JOB_TEST
(TEST_NUMBER,JOB_KEY)；

然后运行最初的sql,好像还是很慢...

anlinew

原帖由 tan9030 于 2008-3-4 17:07 发表


原来的index (JOB_KEY, TEST_NUMBER) ，不能被drop，于是我重新建立了一个(TEST_NUMBER,JOB_KEY)
CREATE UNIQUE INDEX PK_TDB_JOB_TEST_1 ON TDB_JOB_TEST
(TEST_NUMBER,JOB_KEY)；

然后运行最初的sql,好像还是很慢...

新建不好使的 ，换顺序重建就是使job_key的索引在这里不被使用，别的方法做到这个也成，呵呵
因为是pk引用的索引，所以不能drop？

[ 本帖最后由 anlinew 于 2008-3-5 09:45 编辑 ]

tan9030

原帖由 anlinew 于 2008-3-5 09:43 发表

新建不好使的 ，换顺序重建就是使job_key的索引在这里不被使用，别的方法做到这个也成，呵呵
因为是pk引用的索引，所以不能drop？

各位帮忙的，看客，多谢大家的支持，我今天上午到现在用了6个小时的时间对表索引进行了分析，脚本如下：
sql> alter session set sort_area_size=20971520;
sql> set serveroutput on size 1000000
sql>  execute dbms_starts.gather_schema_stats (ownname='EDAUSER',cascade=>TRUE,estimate_percent=>dbms_stats.auto_sample_size);

执行完成后，我在使用最初没有hint的sql, 2分多种就可以得到正确的结果。

rollingpig

现在的SQL_PLAN是怎么样的

anlinew

原帖由 tan9030 于 2008-3-5 14:45 发表


各位帮忙的，看客，多谢大家的支持，我今天上午到现在用了6个小时的时间对表索引进行了分析，脚本如下：
sql> alter session set sort_area_size=20971520;
sql> set serveroutput on size 1000000
sql>  execute dbms_starts.gather_schema_stats (ownname='EDAUSER',cascade=>TRUE,estimate_percent=>dbms_stats.auto_sample_size);

执行完成后，我在使用最初没有hint的sql, 2分多种就可以得到正确的结果。

有成就感不？
继续，

枯荣长老

2分钟的查询，其效率还是无法让人满意的。

tan9030

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=956 Card=1 Bytes=58)
   1    0   SORT (AGGREGATE)
   2    1     NESTED LOOPS (Cost=956 Card=1 Bytes=58)
   3    2       NESTED LOOPS (Cost=880 Card=38 Bytes=1672)
   4    3         NESTED LOOPS (Cost=787 Card=31 Bytes=899)
   5    4           TABLE ACCESS (BY INDEX ROWID) OF 'TDB_REGISTER_WL'
           (Cost=379 Card=408 Bytes=7752)

   6    5             INDEX (RANGE SCAN) OF 'IDX_TDB_REG_WL_START_T' (
          NON-UNIQUE) (Cost=4 Card=408)

   7    4           INDEX (UNIQUE SCAN) OF 'PK_TDB_JOB_TEST' (UNIQUE)
          (Cost=1 Card=1 Bytes=10)

   8    3         INDEX (RANGE SCAN) OF 'PK_TDB_TEST_RESULTS_WL' (UNIQ
          UE) (Cost=3 Card=1 Bytes=15)

   9    2       TABLE ACCESS (BY INDEX ROWID) OF 'TDB_PART_RESULTS_WL'
           (Cost=2 Card=1 Bytes=14)

  10    9         INDEX (UNIQUE SCAN) OF 'PK_TDB_PART_RESULTS_WL' (UNI
          QUE) (Cost=1 Card=1)





Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     111267  consistent gets
       1147  physical reads
          0  redo size
        493  bytes sent via SQL*Net to client
        655  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> SQL> SQL> SQL>