ITPUB论坛－专业的IT技术社区

登录 注册
ITPUB论坛－专业的IT技术社区»论坛 › ≡ 大数据与数据库 ≡ › Oracle数据库管理 › EXISTS 和 IN ,NOT EXISTS 和 NOT IN的效率比较
123下一页
返回列表 发新帖
查看: 31659|回复: 22
收藏 | 打印 上一主题 下一主题

EXISTS 和 IN ,NOT EXISTS 和 NOT IN的效率比较

[复制链接]
BTxigua
论坛徽章:
13
数据库板块每日发贴之星 日期:2007-09-20 01:04:22铁扇公主 日期:2012-02-21 15:02:402010新春纪念徽章 日期:2010-03-01 11:08:28月度精华徽章 日期:2009-04-01 02:15:18数据库板块每日发贴之星 日期:2008-05-17 01:02:08生肖徽章2007版:兔 日期:2008-04-07 19:49:48生肖徽章2007版:鼠 日期:2008-01-02 17:35:53生肖徽章2007版:鸡 日期:2008-01-02 17:35:53ITPUB新首页上线纪念徽章 日期:2007-10-20 08:38:44数据库板块每日发贴之星 日期:2007-10-20 01:03:31
跳转到指定楼层
1#
发表于 2008-10-14 00:31 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
在我们一般的观点中，总是认为使用EXISTS(或NOT EXISTS)通常将提高查询的效率，所以一般推荐使用exists来代替in。但实际情况是不是这个样子呢？我们用实际的例子来看一下，我们分别在两种不同的优化器模式下来看。

create table test1 as select * from dba_objects ;
create table test2 as select * from dba_tables ;
create index idx_object_name on test1(object_name) ;
create index idx_table_name on test2(table_name) ;

exec dbms_stats.gather_table_stats('XIGUA','TEST1') ;
exec dbms_stats.gather_table_stats('XIGUA','TEST2') ;


在CBO模式下：
select * from test1
where object_name in
      ( select table_name from test2 where table_name like 'M%') ;
419 rows selected.

Elapsed: 00:00:00.09

Execution Plan
----------------------------------------------------------
Plan hash value: 2580328806

-------------------------------------------------------------------------------

| Id  | Operation            | Name           | Rows  | Bytes | Cost (%CPU)| Tim
e     |

-------------------------------------------------------------------------------

|   0 | SELECT STATEMENT     |                |   423 | 47376 |   163   (2)| 00:
00:02 |

|*  1 |  HASH JOIN RIGHT SEMI|                |   423 | 47376 |   163   (2)| 00:
00:02 |

|*  2 |   INDEX RANGE SCAN   | IDX_TABLE_NAME |   420 |  7980 |     3   (0)| 00:
00:01 |

|*  3 |   TABLE ACCESS FULL  | TEST1          |  1125 |   102K|   160   (2)| 00:
00:02 |

-------------------------------------------------------------------------------Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("OBJECT_NAME"="TABLE_NAME")
   2 - access("TABLE_NAME" LIKE 'M%')
       filter("TABLE_NAME" LIKE 'M%')
   3 - filter("OBJECT_NAME" LIKE 'M%')

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        727  consistent gets
          0  physical reads
          0  redo size
      22152  bytes sent via SQL*Net to client
        682  bytes received via SQL*Net from client
         29  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        419  rows processed

select * from test1
where exists
      ( select 1 from test2 where test1.object_name = test2.table_name and test2.table_name like 'M%') ;
419 rows selected.

Elapsed: 00:00:00.08

Execution Plan
----------------------------------------------------------
Plan hash value: 2580328806

| Id  | Operation            | Name           | Rows  | Bytes | Cost (%CPU)| Tim
e     |

-------------------------------------------------------------------------------|   0 | SELECT STATEMENT     |                |   423 | 47376 |   163   (2)| 00:
00:02 |

|*  1 |  HASH JOIN RIGHT SEMI|                |   423 | 47376 |   163   (2)| 00:
00:02 |

|*  2 |   INDEX RANGE SCAN   | IDX_TABLE_NAME |   420 |  7980 |     3   (0)| 00:
00:01 |

|*  3 |   TABLE ACCESS FULL  | TEST1          |  1125 |   102K|   160   (2)| 00:
00:02 |

-------------------------------------------------------------------------------Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("TEST1"."OBJECT_NAME"="TEST2"."TABLE_NAME")
   2 - access("TEST2"."TABLE_NAME" LIKE 'M%')
       filter("TEST2"."TABLE_NAME" LIKE 'M%')
   3 - filter("TEST1"."OBJECT_NAME" LIKE 'M%')

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        727  consistent gets
          0  physical reads
          0  redo size
      22152  bytes sent via SQL*Net to client
        682  bytes received via SQL*Net from client
         29  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        419  rows processed
在CBO模式下，我们可以看到这两者的执行计划完全相同，统计数据也相同。

我们再来看一下RBO模式下的情况，这种情况相对复杂一些。
SQL> select /*+ rule */ * from test1
  2  where object_name in
  3        ( select table_name from test2 where table_name like 'M%') ;

419 rows selected.

Elapsed: 00:00:00.13

Execution Plan
----------------------------------------------------------
Plan hash value: 618497113

-------------------------------------------------------
| Id  | Operation                   | Name            |
-------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST1           |
|   2 |   NESTED LOOPS              |                 |
|   3 |    VIEW                     | VW_NSO_1        |
|   4 |     SORT UNIQUE             |                 |
|*  5 |      INDEX RANGE SCAN       | IDX_TABLE_NAME  |
|*  6 |    INDEX RANGE SCAN         | IDX_OBJECT_NAME |
-------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("TABLE_NAME" LIKE 'M%')
       filter("TABLE_NAME" LIKE 'M%')
   6 - access("OBJECT_NAME"="$nso_col_1")

Note
-----
   - rule based optimizer used (consider using cbo)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        646  consistent gets
          0  physical reads
          0  redo size
      27884  bytes sent via SQL*Net to client
        682  bytes received via SQL*Net from client
         29  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        419  rows processed

SQL> select /*+ rule */ * from test1
  2  where exists
  3        ( select 1 from test2 where test1.object_name = test2.table_name and test2.table_name like 'M%') ;     

419 rows selected.

Elapsed: 00:00:00.87

Execution Plan
----------------------------------------------------------
Plan hash value: 1694944701

---------------------------------------------
| Id  | Operation          | Name           |
---------------------------------------------
|   0 | SELECT STATEMENT   |                |
|*  1 |  FILTER            |                |
|   2 |   TABLE ACCESS FULL| TEST1          |
|*  3 |   INDEX RANGE SCAN | IDX_TABLE_NAME |
---------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( EXISTS (SELECT 0 FROM "TEST2" "TEST2" WHERE
              "TEST2"."TABLE_NAME"=:B1 AND "TEST2"."TABLE_NAME" LIKE 'M%'))
   3 - access("TEST2"."TABLE_NAME"=:B1)
       filter("TEST2"."TABLE_NAME" LIKE 'M%')

Note
-----
   - rule based optimizer used (consider using cbo)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      70840  consistent gets
          0  physical reads
          0  redo size
      22152  bytes sent via SQL*Net to client
        682  bytes received via SQL*Net from client
         29  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        419  rows processed
在这里，我们可以看到实际上，使用in效率比exists效率更高。我们可以这样来理解这种情况：
对于in，rule优化器选择的内存查询的结果作为驱动表来进行nest loops连接，所以当内存查询的结果集比较小的时候，这个in的效率还是比较高的。
对于exists，则是利用外查询表的全表扫描结果集过滤内查询的结果集，当外查询的表比较大的时候，相对效率比较低。

再来看一下内查询结果集比较大，而外查询较小的时候的情况。

SQL> select /*+ rule */ * from test2
where exists
  2    3        ( select 1 from test1 where test1.object_name = test2.table_name and test1.object_name like 'S%') ;

172 rows selected.

Elapsed: 00:00:00.08

Execution Plan
----------------------------------------------------------
Plan hash value: 833525739

----------------------------------------------
| Id  | Operation          | Name            |
----------------------------------------------
|   0 | SELECT STATEMENT   |                 |
|*  1 |  FILTER            |                 |
|   2 |   TABLE ACCESS FULL| TEST2           |
|*  3 |   INDEX RANGE SCAN | IDX_OBJECT_NAME |
----------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( EXISTS (SELECT 0 FROM "TEST1" "TEST1" WHERE
              "TEST1"."OBJECT_NAME"=:B1 AND "TEST1"."OBJECT_NAME" LIKE 'S%'))
   3 - access("TEST1"."OBJECT_NAME"=:B1)
       filter("TEST1"."OBJECT_NAME" LIKE 'S%')

Note
-----
   - rule based optimizer used (consider using cbo)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4837  consistent gets
          0  physical reads
       2596  redo size
      13642  bytes sent via SQL*Net to client
        506  bytes received via SQL*Net from client
         13  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        172  rows processed

SQL> select /*+ rule */ * from test2
  2  where table_name in
  3        ( select object_name from test1 where object_name like 'S%') ;

172 rows selected.

Elapsed: 00:00:00.12

Execution Plan
----------------------------------------------------------
Plan hash value: 2497755124

-------------------------------------------------------
| Id  | Operation                   | Name            |
-------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST2           |
|   2 |   NESTED LOOPS              |                 |
|   3 |    VIEW                     | VW_NSO_1        |
|   4 |     SORT UNIQUE             |                 |
|*  5 |      INDEX RANGE SCAN       | IDX_OBJECT_NAME |
|*  6 |    INDEX RANGE SCAN         | IDX_TABLE_NAME  |
-------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("OBJECT_NAME" LIKE 'S%')
       filter("OBJECT_NAME" LIKE 'S%')
   6 - access("TABLE_NAME"="$nso_col_1")

Note
-----
   - rule based optimizer used (consider using cbo)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2214  consistent gets
          0  physical reads
       7556  redo size
      13378  bytes sent via SQL*Net to client
        506  bytes received via SQL*Net from client
         13  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        172  rows processed

从理论上分析，当内存查询的结果集比较大，而外查询比较小的时候，应该增加in的cost，对于exists的filter来说，也应该效率有所提高，所以再这种情况下，我们应该看到exists效率更高。但是在实际的测试中，我们可以看到，这两者并不存在明显的性能上的差异，甚至于用in的效果比exists更好。

总结：
1、在CBO模式下，两者效率一致。
2、在RBO模式下，当外层数据集远大于内层数据集时，使用in的效率比较高。
3、在RBO模式下，当外层数据集远小于内层数据集时，两者效率相差不大。


    可能我的测试数据选择不太理想，欢迎大家讨论。


==========
补充not exists和not in的测试数据
先来看一下CBO模式下的情况：
SQL> select * from test2
  2  where table_name not in
  3        ( select object_name from test1 where object_name like 'A%') ;   

2950 rows selected.

Elapsed: 00:00:13.93

Execution Plan
----------------------------------------------------------
Plan hash value: 833525739

---------------------------------------------------------------------------

| Id  | Operation          | Name            | Rows  | Bytes | Cost (%CPU)| Time
     |

---------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |                 |  1576 |   315K|  6364   (1)| 00:0
1:17 |

|*  1 |  FILTER            |                 |       |       |            |
     |

|   2 |   TABLE ACCESS FULL| TEST2           |  1577 |   315K|    14   (0)| 00:0
0:01 |

|*  3 |   INDEX RANGE SCAN | IDX_OBJECT_NAME |     1 |    25 |     8   (0)| 00:0
0:01 |

---------------------------------------------------------------------------


Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "TEST1" "TEST1" WHERE
              "OBJECT_NAME" LIKE 'A%' AND LNNVL("OBJECT_NAME"<>:B1)))
   3 - access("OBJECT_NAME" LIKE 'A%')
       filter("OBJECT_NAME" LIKE 'A%' AND LNNVL("OBJECT_NAME"<>:B1))


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      60806  consistent gets
         29  physical reads
       1104  redo size
     165661  bytes sent via SQL*Net to client
       2541  bytes received via SQL*Net from client
        198  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       2950  rows processed

SQL> select * from test2
  2  where not exists
  3        ( select 1 from test1 where test1.object_name = test2.table_name and test1.object_name like 'A%') ;

2950 rows selected.

Elapsed: 00:00:00.19

Execution Plan
----------------------------------------------------------
Plan hash value: 349475409

-------------------------------------------------------------------------------

| Id  | Operation            | Name            | Rows  | Bytes | Cost (%CPU)| Ti
me     |

--------------------------------------------------------------------------------
--------

|   0 | SELECT STATEMENT     |                 |  1538 |   345K|    23   (5)| 00
:00:01 |

|*  1 |  HASH JOIN RIGHT ANTI|                 |  1538 |   345K|    23   (5)| 00
:00:01 |

|*  2 |   INDEX RANGE SCAN   | IDX_OBJECT_NAME |  1259 | 31475 |     8   (0)| 00
:00:01 |

|   3 |   TABLE ACCESS FULL  | TEST2           |  1577 |   315K|    14   (0)| 00
:00:01 |

-------------------------------------------------------------------------------


Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("TEST1"."OBJECT_NAME"="TEST2"."TABLE_NAME")
   2 - access("TEST1"."OBJECT_NAME" LIKE 'A%')
       filter("TEST1"."OBJECT_NAME" LIKE 'A%')


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        314  consistent gets
          0  physical reads
          0  redo size
     165661  bytes sent via SQL*Net to client
       2541  bytes received via SQL*Net from client
        198  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       2950  rows processed

在CBO模式下，not in采用的是filter，对外层表做全表扫描，再去filter内层查询结果集。not exists采用内层查询结果集作hash join连接。
从结果明显可以看到，not exists效率比较高。把内层和外层的表对换一下，结果也是相同的，not exists的效率明显高很多。


在rule模式下：
SQL> select /*+ rule */ * from test1
  2  where object_name not in
  3        ( select table_name from test2 where table_name like 'A%' ) ;

229092 rows selected.

Elapsed: 00:00:22.34

Execution Plan
----------------------------------------------------------
Plan hash value: 1694944701

---------------------------------------------
| Id  | Operation          | Name           |
---------------------------------------------
|   0 | SELECT STATEMENT   |                |
|*  1 |  FILTER            |                |
|   2 |   TABLE ACCESS FULL| TEST1          |
|*  3 |   INDEX RANGE SCAN | IDX_TABLE_NAME |
---------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( NOT EXISTS (SELECT 0 FROM "TEST2" "TEST2" WHERE
              LNNVL("TABLE_NAME"<>:B1) AND "TABLE_NAME" LIKE 'A%'))
   3 - access("TABLE_NAME" LIKE 'A%')
       filter(LNNVL("TABLE_NAME"<>:B1) AND "TABLE_NAME" LIKE 'A%')

Note
-----
   - rule based optimizer used (consider using cbo)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     348779  consistent gets
          0  physical reads
          0  redo size
   11059645  bytes sent via SQL*Net to client
     168377  bytes received via SQL*Net from client
      15274  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     229092  rows processed

SQL>
SQL> select /*+ rule */ * from test1
  2  where not exists
  3        ( select 1 from test2 where test1.object_name = test2.table_name and test2.table_name like 'A%' ) ;

229092 rows selected.

Elapsed: 00:00:08.00

Execution Plan
----------------------------------------------------------
Plan hash value: 1694944701

---------------------------------------------
| Id  | Operation          | Name           |
---------------------------------------------
|   0 | SELECT STATEMENT   |                |
|*  1 |  FILTER            |                |
|   2 |   TABLE ACCESS FULL| TEST1          |
|*  3 |   INDEX RANGE SCAN | IDX_TABLE_NAME |
---------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( NOT EXISTS (SELECT 0 FROM "TEST2" "TEST2" WHERE
              "TEST2"."TABLE_NAME"=:B1 AND "TEST2"."TABLE_NAME" LIKE 'A%'))
   3 - access("TEST2"."TABLE_NAME"=:B1)
       filter("TEST2"."TABLE_NAME" LIKE 'A%')

Note
-----
   - rule based optimizer used (consider using cbo)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     352897  consistent gets
          0  physical reads
          0  redo size
   11059645  bytes sent via SQL*Net to client
     168377  bytes received via SQL*Net from client
      15274  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     229092  rows processed

在RBO模式下，两者的执行计划完全相同。
总结：
1、CBO模式下，not exists效率较高。
2、RBO模式下，两者效率差不多。

[ 本帖最后由 BTxigua 于 2008-10-14 10:42 编辑 ]
EXISTS, 效率, create, table, select

使用道具 举报

回复
bolun761
论坛徽章:
12
授权会员 日期:2007-07-11 20:34:40鲜花蛋 日期:2011-11-24 21:31:102010新春纪念徽章 日期:2010-03-01 11:19:07生肖徽章2007版:猪 日期:2009-12-09 20:13:20生肖徽章2007版:兔 日期:2009-11-24 12:05:57ITPUB8周年纪念徽章 日期:2009-09-27 10:21:20生肖徽章2007版:鼠 日期:2009-09-10 15:41:532009新春纪念徽章 日期:2009-01-04 14:52:28生肖徽章2007版:鸡 日期:2008-12-01 16:52:42奥运会纪念徽章:花样游泳 日期:2008-10-24 13:28:54
2#
发表于 2008-10-14 07:31 | 只看该作者
嘿嘿，支持原创，建议：
1.把数据库版本也考虑进来;
2.增加not in ,not exists,直连接方式的对比。

今天下午有时间的时候我也来测试一把，但我的环境可能仅限在oracle 9i

使用道具 举报

回复
OneGoodDream
论坛徽章:
4
祖国60周年纪念徽章 日期:2009-10-09 08:28:00
3#
发表于 2008-10-14 08:27 | 只看该作者
非常不错。先谢谢了。

等一下也去试验一下。

使用道具 举报

回复
zuohao_lu
论坛徽章:
97
ITPUB十周年纪念徽章 日期:2011-11-01 16:24:04
4#
发表于 2008-10-14 08:30 | 只看该作者
收藏.支持!

使用道具 举报

回复
itpub_2000
论坛徽章:
27
奥运会纪念徽章:花样游泳 日期:2008-08-12 10:14:22奥运会纪念徽章:跳水 日期:2012-08-09 21:18:462012新春纪念徽章 日期:2012-01-04 11:54:26蛋疼蛋 日期:2011-07-03 12:15:012011新春纪念徽章 日期:2011-02-18 11:43:322011新春纪念徽章 日期:2011-01-04 10:35:17ITPUB9周年纪念徽章 日期:2010-10-08 09:31:212010年世界杯参赛球队：巴拉圭 日期:2010-04-12 10:45:252010新春纪念徽章 日期:2010-03-01 11:19:502010新春纪念徽章 日期:2010-01-04 08:33:08
5#
发表于 2008-10-14 08:40 | 只看该作者
好东西，mark

使用道具 举报

回复
阿日
论坛徽章:
27
设计板块每日发贴之星 日期:2007-08-24 01:05:17奥运会纪念徽章:拳击 日期:2012-06-25 14:17:112012新春纪念徽章 日期:2012-01-04 11:49:54生肖徽章2007版:龙 日期:2009-04-07 18:18:35生肖徽章2007版:鸡 日期:2008-10-14 14:14:30生肖徽章2007版:龙 日期:2008-10-08 21:22:20铁扇公主 日期:2008-09-28 11:20:58授权会员 日期:2008-09-05 13:30:44ITPUB元老 日期:2008-09-05 13:30:31奥运会纪念徽章:摔跤 日期:2008-07-26 08:05:05
6#
发表于 2008-10-14 08:47 | 只看该作者
不错，学习了
以前也看过讨论exists和in的比较，对于数据量较大的用exists，较小时用in会更快一些，但分析的没有楼主详细，支持

使用道具 举报

回复
OneGoodDream
论坛徽章:
4
祖国60周年纪念徽章 日期:2009-10-09 08:28:00
7#
发表于 2008-10-14 08:52 | 只看该作者
弱弱的问一个问题，
在CBO模式下，是通过 Cost (%CPU) 比较效率。
但是 RBO模式下，怎么看出来 “使用in效率比exists效率更高”？
是通过 consistent gets 的值的大小？

使用道具 举报

回复
netbbs
论坛徽章:
1
ITPUB新首页上线纪念徽章 日期:2007-10-20 08:38:44
8#
发表于 2008-10-14 08:53 | 只看该作者
exists 比in效率高是因为在有重复值是，只需扫到第一个就可停止扫描。

第二个表tablename是唯一的，另外搞了个like %M造成全表扫描，都导致你这个测试说明不了问题。

使用道具 举报

回复
BTxigua
论坛徽章:
13
数据库板块每日发贴之星 日期:2007-09-20 01:04:22铁扇公主 日期:2012-02-21 15:02:402010新春纪念徽章 日期:2010-03-01 11:08:28月度精华徽章 日期:2009-04-01 02:15:18数据库板块每日发贴之星 日期:2008-05-17 01:02:08生肖徽章2007版:兔 日期:2008-04-07 19:49:48生肖徽章2007版:鼠 日期:2008-01-02 17:35:53生肖徽章2007版:鸡 日期:2008-01-02 17:35:53ITPUB新首页上线纪念徽章 日期:2007-10-20 08:38:44数据库板块每日发贴之星 日期:2007-10-20 01:03:31
9#
 楼主| 发表于 2008-10-14 09:15 | 只看该作者
原帖由 netbbs 于 2008-10-14 08:53 发表
exists 比in效率高是因为在有重复值是，只需扫到第一个就可停止扫描。

第二个表tablename是唯一的，另外搞了个like %M造成全表扫描，都导致你这个测试说明不了问题。


第二个表，我再次插入了一份，table_name有重复值。
原来的全表扫描是因为M%表占的记录数比较多。我换A%，就可以使用range scan。测试了第一种情况，在cbo模式下，两者的执行计划还是相同。

SQL> select count(*) from test1 ;

  COUNT(*)
----------
    229504
SQL> select count(*) from dba_objects ;

  COUNT(*)
----------
     50321
SQL> insert into test2 select * from test2 ;

1577 rows created.

Elapsed: 00:00:00.11
SQL> commit;

Commit complete.

SQL> set autotrace traceonly
SQL> select /* + rule */ * from test1
  2  where object_name in
  3        ( select table_name from test2 where table_name like 'A%') ;

412 rows selected.

Elapsed: 00:00:00.04

Execution Plan
----------------------------------------------------------
Plan hash value: 3246190761

--------------------------------------------------------------------------------
---------------

| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%C
PU)| Time     |

--------------------------------------------------------------------------------
---------------

|   0 | SELECT STATEMENT            |                 |   104 | 11648 |   107
(1)| 00:00:02 |

|   1 |  TABLE ACCESS BY INDEX ROWID| TEST1           |     1 |    93 |     2
(0)| 00:00:01 |

|   2 |   NESTED LOOPS              |                 |   104 | 11648 |   107
(1)| 00:00:02 |

|   3 |    SORT UNIQUE              |                 |   104 |  1976 |     2
(0)| 00:00:01 |

|*  4 |     INDEX RANGE SCAN        | IDX_TABLE_NAME  |   104 |  1976 |     2
(0)| 00:00:01 |

|*  5 |    INDEX RANGE SCAN         | IDX_OBJECT_NAME |     1 |       |     1
(0)| 00:00:01 |

--------------------------------------------------------------------------------
---------------


Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("TABLE_NAME" LIKE 'A%')
       filter("TABLE_NAME" LIKE 'A%')
   5 - access("OBJECT_NAME"="TABLE_NAME")
       filter("OBJECT_NAME" LIKE 'A%')


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        667  consistent gets
          0  physical reads
          0  redo size
      12041  bytes sent via SQL*Net to client
        682  bytes received via SQL*Net from client
         29  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        412  rows processed

SQL> select /* + rule */ * from test1
  2  where exists
  3        ( select 1 from test2 where test1.object_name = test2.table_name and test2.table_name like 'A%') ;

412 rows selected.

Elapsed: 00:00:00.03

Execution Plan
----------------------------------------------------------
Plan hash value: 3246190761

--------------------------------------------------------------------------------
---------------

| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%C
PU)| Time     |

--------------------------------------------------------------------------------
---------------

|   0 | SELECT STATEMENT            |                 |   104 | 11648 |   107
(1)| 00:00:02 |

|   1 |  TABLE ACCESS BY INDEX ROWID| TEST1           |     1 |    93 |     2
(0)| 00:00:01 |

|   2 |   NESTED LOOPS              |                 |   104 | 11648 |   107
(1)| 00:00:02 |

|   3 |    SORT UNIQUE              |                 |   104 |  1976 |     2
(0)| 00:00:01 |

|*  4 |     INDEX RANGE SCAN        | IDX_TABLE_NAME  |   104 |  1976 |     2
(0)| 00:00:01 |

|*  5 |    INDEX RANGE SCAN         | IDX_OBJECT_NAME |     1 |       |     1
(0)| 00:00:01 |

--------------------------------------------------------------------------------
---------------


Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("TEST2"."TABLE_NAME" LIKE 'A%')
       filter("TEST2"."TABLE_NAME" LIKE 'A%')
   5 - access("TEST1"."OBJECT_NAME"="TEST2"."TABLE_NAME")
       filter("TEST1"."OBJECT_NAME" LIKE 'A%')


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        667  consistent gets
          0  physical reads
          0  redo size
      12041  bytes sent via SQL*Net to client
        682  bytes received via SQL*Net from client
         29  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        412  rows processed

使用道具 举报

回复
pineapple2006
论坛徽章:
4
奥运会纪念徽章:摔跤 日期:2008-08-05 18:22:34生肖徽章2007版:牛 日期:2008-12-25 09:31:58生肖徽章2007版:鼠 日期:2009-08-31 09:41:222010新春纪念徽章 日期:2010-03-01 11:20:04
10#
发表于 2008-10-14 09:40 | 只看该作者
这样的帖子多起来,大家就可以少看一些英文文挡了.但从长远的角度来看,也未必是一件好事.(个人观点)

使用道具 举报

回复

123下一页
返回列表 发新帖
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有　联系我们 未成年人举报专区　
京ICP备16024965号-8 　北京市公安局海淀分局网监中心备案编号：11010802021510　广播电视节目制作经营许可证：编号（京）字第1149号   
快速回复 返回顶部 返回列表