自连接 in和exits比较

先看我从网上找的一段话：

*************************************开始线***********************************************

有两个简单例子，以说明 “exists”和“in”的效率问题

1) select * from T1 where exists(select 1 from T2 whereT1.a=T2.a) ;

T1数据量小而T2数据量非常大时，T1<<T2时，1) 的查询效率高。

2) select * from T1 where T1.a in (select T2.a from T2) ;

T1数据量非常大而T2数据量小时，T1>>T2时，2) 的查询效率高。

exists 用法：

其中 “select 1 from T2 where T1.a=T2.a” 相当于一个关联表查询，相当于

“select 1 from T1,T2 whereT1.a=T2.a”

但是，如果你当当执行 1） 句括号里的语句，是会报语法错误的，这也是使用exists需要注意的地方。

“exists（xxx）”就表示括号里的语句能不能查出记录，它要查的记录是否存在。

因此“select 1”这里的“1”其实是无关紧要的，换成“*”也没问题，它只在乎括号里的数据能不能查找出来，是否存在这样的记录，如果存在，这 1） 句的where条件成立。

in 的用法：

继续引用上面的例子

“2) select * from T1 where T1.a in (select T2.a from T2) ”

这里的“in”后面括号里的语句搜索出来的字段的内容一定要相对应，一般来说，T1和T2这两个表的a字段表达的意义应该是一样的，否则这样查没什么意义。

打个比方：T1，T2表都有一个字段，表示工单号，但是T1表示工单号的字段名叫“ticketid”，T2则为“id”，但是其表达的意义是一样的，而且数据格式也是一样的。这时，用2）的写法就可以这样：

“select * from T1 where T1.ticketid in (select T2.id from T2)”

Select name from employee where name not in (select name fromstudent);

Select name from employee where not exists (select name fromstudent);

第一句SQL语句的执行效率不如第二句。

通过使用EXISTS，Oracle会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。Oracle在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因

*************************************结束线***********************************************

如果两个表数相当呢，那么应该用什么呢？看下面的两个列子

1）使用in

select distinct to_char(t.operate_time,'yyyy-MM-dd') as operate_time,t.machineid from jscnbi.bi_logfile t where t.machineid in (
            select distinct t.machineid
                  from jscnbi.bi_logfile t
                 where t.operate_time < trunc(sysdate)
                   and t.operate_time >= trunc(sysdate)-1)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3     52.88      51.65      32394      48663          0        2075
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5     52.88      51.65      32394      48663          0        2075

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 82

Rows     Row Source Operation
-------  ---------------------------------------------------
   2075  HASH UNIQUE (cr=48663 pr=32394 pw=0 time=51655844 us)
78208204   FILTER  (cr=48663 pr=32394 pw=0 time=312853616 us)
78208204    HASH JOIN  (cr=48663 pr=32394 pw=0 time=78228988 us)
   8961     TABLE ACCESS BY INDEX ROWID BI_LOGFILE (cr=3115 pr=0 pw=0 time=62808 us)
   8961      INDEX RANGE SCAN IND_BI_LOGFILE_2 (cr=27 pr=0 pw=0 time=26962 us)(object id 78233)
1132012     TABLE ACCESS FULL BI_LOGFILE (cr=45548 pr=32394 pw=0 time=1132130 us)

2）使用exits

select  distinct to_char(t.operate_time,'yyyy-MM-dd') as operate_time,t.machineid from jscnbi.bi_logfile t where exists (
            select 1
                  from jscnbi.bi_logfile tt
                 where tt.operate_time < trunc(sysdate)-2
                   and tt.operate_time >= trunc(sysdate)-3
                   and tt.machineid = t.machineid)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      1.01       0.99      32519      48663          0        2075
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      1.02       0.99      32519      48663          0        2075

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82

Rows     Row Source Operation
-------  ---------------------------------------------------
   2075  HASH UNIQUE (cr=48663 pr=32519 pw=0 time=1002840 us)
 151147   FILTER  (cr=48663 pr=32519 pw=0 time=1531760 us)
 151147    HASH JOIN RIGHT SEMI (cr=48663 pr=32519 pw=0 time=1078311 us)
   8961     TABLE ACCESS BY INDEX ROWID BI_LOGFILE (cr=3115 pr=1 pw=0 time=53836 us)
   8961      INDEX RANGE SCAN IND_BI_LOGFILE_2 (cr=27 pr=0 pw=0 time=17965 us)(object id 78233)
1132012     TABLE ACCESS FULL BI_LOGFILE (cr=45548 pr=32518 pw=0 time=1132114 us)
     

比较上面两个差别，发现基本上一样，但是红色的部分，是不是也就意味着差不多的时候也是用的exists呢？恩，应该是这样的！