自连接 in和exits比较

最新推荐文章于 2024-10-27 08:00:00 发布

最新推荐文章于 2024-10-27 08:00:00 发布 · 134 阅读

文章标签：

#数据库

本文探讨了SQL查询中Exists与In操作符的性能差异，分析了不同数据规模下两者的适用场景，并通过实例对比了它们在实际应用中的执行效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

有两个简单例子，以说明 “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呢？恩，应该是这样的！