Oracle 11g 递归+ exists执行计划的改变(3)

我看了一下in 和 exists产生执行计划的区别,从谓词从看到exists需要没有展开,所以我加了一个Hint验证了一下,执行结果跟in就是一样的了。
--unnest为展开子查询
SQL> SELECT *
  FROM (SELECT DISTINCT A.*
          FROM GG_MATERIAL_CLASSIFY A
        CONNECT BY PRIOR PARENT_CLASSIFY_ID = CLASSIFY_ID
          START WITH exists
                    (SELECT /*+unnest*/DISTINCT M.CLASSIFY_ID
                        FROM GG_DISTRIBUTION D, GG_MATERIAL M
                      WHERE D.MATERIAL_ID = M.MATERIAL_ID
                        AND A.CLASSIFY_ID=M.CLASSIFY_ID
                        AND D.ACTUAL_QTY > 0
                        AND D.DATA_AREA LIKE '03%')) B
  WHERE B.PARENT_CLASSIFY_ID = '201'
  ORDER BY B.CODE ASC;
已选择11行。
已用时间:  00: 00: 01.18
执行计划
----------------------------------------------------------
Plan hash value: 2653190462
----------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time    | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT                          |                          |  3246 |  3445K|      | 16641  (1)| 00:03:20 |      |      |
|  1 |  SORT ORDER BY                            |                          |  3246 |  3445K|      | 16641  (1)| 00:03:20 |      |      |
|*  2 |  VIEW                                    |                          |  3246 |  3445K|      | 16641  (1)| 00:03:20 |      |      |
|  3 |    HASH UNIQUE                            |                          |  3246 |  653K|      | 16641  (1)| 00:03:20 |      |      |
|*  4 |    CONNECT BY WITHOUT FILTERING (UNIQUE) |                          |      |      |      |            |          |      |      |
|*  5 |      HASH JOIN SEMI                      |                          |  1623 |  256K|      | 16626  (1)| 00:03:20 |      |      |
|  6 |      TABLE ACCESS FULL                  | GG_MATERIAL_CLASSIFY    |  1864 |  262K|      |    14  (0)| 00:00:01 |      |      |
|  7 |      VIEW                                | VW_SQ_1                  |  144K|  2533K|      | 16610  (1)| 00:03:20 |      |      |
|*  8 |        HASH JOIN                          |                          |  144K|  6051K|  3784K| 16610  (1)| 00:03:20 |      |      |
|  9 |        INDEX FAST FULL SCAN              | INX_GG_MATERIAL_CLASSIFY |  117K|  2403K|      |  145  (2)| 00:00:02 |      |      |
|* 10 |        TABLE ACCESS BY GLOBAL INDEX ROWID| GG_DISTRIBUTION          |  144K|  3097K|      | 16045  (1)| 00:03:13 | ROWID | ROWID |
|* 11 |          INDEX RANGE SCAN                | IX_DISTRIBU_ACT_QTY01    |  144K|      |      |  346  (1)| 00:00:05 |      |      |
|  12 |      TABLE ACCESS FULL                    | GG_MATERIAL_CLASSIFY    |  1864 |  262K|      |    14  (0)| 00:00:01 |      |      |
----------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  2 - filter("B"."PARENT_CLASSIFY_ID"='201')
  4 - access("CLASSIFY_ID"=PRIOR "PARENT_CLASSIFY_ID")
  5 - access("A"."CLASSIFY_ID"="ITEM_0")
  8 - access("D"."MATERIAL_ID"="M"."MATERIAL_ID")
  10 - filter("D"."DATA_AREA" LIKE '03%')
  11 - access("D"."ACTUAL_QTY">0)
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
    113928  consistent gets
          0  physical reads
          0  redo size
      1960  bytes sent via SQL*Net to client
        338  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          3  sorts (memory)
          0  sorts (disk)
        11  rows processed

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/9cfc46e3fa0ba17781a6a4e99bc01d79.html