大家好，今天小编来为大家解答EXISTS 真的比IN 快吗？这个问题，很多人还不知道，现在让我们一起来看看吧！

接下来我们来验证一下对于NULL值和一般数据来说IN、EXISTS、NOT IN、NOT EXISTS是否有区别。因此，我们需要准备一些数据。我们需要一个名为DEMO_WYDXBG 的表。表中数据如下所示：

验证NULL值和普通值对IN和NOT IN的影响

从DEMO_WYDXBG A WHERE F1 IN(1,NULL) 中选择F1,F6;

执行结果显示，当列表中存在NULL时，IN可以正常查询结果。

从DEMO_WYDXBG 中选择F1,F6，其中F1 NOT IN(1,NULL);

执行结果显示，当列表中有NULL时，NOT IN无法查询到任何结果。

验证NULL值和普通值对EXISTS和NOT EXISTS的影响

SELECT F1,F6 FROM DEMO_WYDXBG A WHERE EXISTS(SELECT 1 FROM DEMO_WYDXBG B WHERE A.F1=B.F1 AND (A.F1=1 OR A.F1 IS NULL))

执行结果显示，当子查询数据包含NULL时，EXISTS可以正常查询结果，并且结果与IN查询的结果一致。

从DEMO_WYDXBG A 中选择F1,F6，其中不存在（从DEMO_WYDXBG B 中选择1，其中A.F1=B.F1 AND（A.F1=1 或A.F1 为NULL））

执行结果显示，当子查询数据包含NULL时，NOT EXISTS可以正常查询结果。

所以通过上面的例子我们可以得出以下结论：

IN、NOT IN 和EXISTS、NOT EXISTS 条件的含义不同。 IN 和EXISTS 在数据处理上没有区别。处理NULL 值时NOT IN 和NOT EXISTS 有不同的结果。那么为什么当NULL存在时NOT IN就不能查询结果呢？但NOT EXISTS可以吗？

不在的情况下

F1 NOT IN(1,NULL) 相当于F1！=1 AND F1 !=NULL 因为NULL 和任何表达式计算的结果都是未知的，所以当条件包含NULL 值时，条件一定不为真。所以当F1！=1 条件成立，但由于F1 !=NULL 条件不成立，因此无法获得结果。

那么为什么NOT EXISTS 不行呢？我们得从EXISTS的含义来解释。 EXISTS用于判断是否有数据。如果有数据，则为TRUE，如果没有，则为FALSE。 NOT EXISTS 恰恰相反。因此，当子查询中的NULL与DEMO_WYDXBG表上的任何数据匹配时，结果无效。因此，它们不能匹配。这意味着没有数据。没有数据就代表TRUE，所以可以查询数据。

IN和EXISTS的效率验证

我们已经验证了IN 和EXISTS 以及NOT IN 和NOT EXISTS 之间的区别。接下来我们要验证一下两者的效率。为此，我们需要创建两个新表，一张名为BIG_TABLE，一张名为SMALL_TABLE。

BIG_TABLE表结构如下：

BIG_TABLE总共有2000万条数据。使用循环随机插入数据。大约有100 万个唯一值。生成数据后，需要进行统计

调用dbms_stats.gather_table_stats(‘WYDXBG’,’BIG_TABLE’);

SMALL_TABLE表结构如下：

SMALL_TABLE总共有20万条数据。循环插入数据，唯一值为100,000。生成数据后，需要进行统计

调用dbms_stats.gather_table_stats(‘WYDXBG’,’SMALL_TABLE’);

首先我们使用BIG_TABLE作为主表，SMALL_TABLE作为子查询中的表，并使用IN的写法。 SQL语句如下：

SELECT * FROM BIG_TABLE T WHERE T.F2 IN(SELECT T1.F2 FROM SMALL_TABLE T1 WHERE T1.F2 :A AND T1.F2=:B)

执行计划如下图所示：

之后我们使用BIG_TABLE作为主表，SMALL_TABLE作为子查询中的表，并使用EXISTS的写法。 SQL语句如下：

SELECT * FROM BIG_TABLE T WHERE EXISTS（SELECT F2 FROM SMALL_TABLE T1 WHERE T.F2=T1.F2 AND T1.F2 :A AND T1.F2=:B）

执行计划如下图所示：

什么？两者的执行计划居然是一样的？这与网上所说的不符。当然，我们不能据此得出两者的执行计划一定相同的结论。因为我们前面看到的执行计划称为预期执行计划，即SQL可能会这样执行，但实际上可能不会这样执行。

为了得到实际的执行计划，我们需要执行SQL。分别代入变量A和B的实际值。本例中A使用100，B使用2000，为了方便查找，在SQL中添加注释/*XYDXBG2021*/，然后执行该SQL。然后可以通过以下SQL语句查询SQL的运行状态select T.PLAN_HASH_VALUE,T.SQL_ID,T.SQL_TEXT from v$sql t where upper(t.sql_text) like ‘%XYDXBG2021%’

这里我们可以看到两条SQL文本不一致，但是它们的PLAN_HASH_VALUE是一致的，这说明两者使用的是同一个执行计划。这意味着使用IN 和EXISTS 在效率上是一致的。

然后我们找到它的详细执行计划来看看。您可以将SQL_ID替换为以下语句来查找真正的执行计划。

从表中选择*(dbms_xplan.display_cursor(‘bh6xzy3wq59u9’));

IN执行计划如下：

EXISTS执行计划如下：

两者确实完全相同，所以我们可以得出结论

当使用BIG_TABLE作为主表，使用SMALL_TABLE作为子查询中的表时，无论使用IN还是EXISTS，两者的效率是相同的。

我们看一下如果使用SMALL_TABLEL作为主表，使用BIG_TABLE作为子查询中的表，两者是否一致？采用IN写法，SQL语句如下：

SELECT * FROM SMALL_TABLE T WHERE T.F2 IN(SELECT T1.F2 FROM BIG_TABLE T1 WHERE T1.F2 :A AND T1.F2=:B)

IN执行计划如下：

采用EXISTS写法，SQL语句如下：

SELECT * FROM SMALL_TABLE T WHERE EXISTS（SELECT F2 FROM BIG_TABLE T1 WHERE T.F2=T1.F2 AND T1.F2 :A AND T1.F2=:B）

EXISTS执行计划如下所示：

两人的预期执行计划是一致的。接下来，将变量A 和B 替换为实际值。本例中A使用100，B使用2000，为了方便查找，在SQL中添加注释/*XYDXBG2021*/，然后执行该SQL。

两条SQL的PLAN_HASH_VALUE一致，说明使用了相同的执行计划。

EXISTS的执行计划如下：

IN的执行计划如下：

两者完全相同，因此我们可以得出结论

当SMALL_TABLE作为主表，BIG_TABLE作为子查询中的表时，无论使用IN还是EXISTS，两者的效率是相同的。

除了上面两个DEMO之外，你还可以验证两个表都使用BIG_TABLE，并且都使用SMALL_TABLE示例，以及NOT EXISTS和NOT IN。你会发现他们的执行计划是一样的。

IN和EXISTS的结论

通过上面的验证，我们看到IN和EXISTS的执行计划是相同的，也就是说两者的性能是一致的。网上说EXISTS比IN快是不正确的。 NOT EXISTS 也不比NOT IN 快。但NOT EXISTS和NOT IN确实可能有不同的结果。所以使用NOT IN时需要特别注意NULL值。

为什么IN和EXISTS的执行计划是一致的？造成这个问题的原因在于Oracle的优化器模式。在基于成本的优化器中，Oracle会评估多个访问路径并最终选择成本最低的执行计划。因此，虽然SQL文本不一致，但是IN和EXISTS访问路径很可能是相同的。同时，Oracle会始终执行查询转换。 IN和EXISTS可以进行查询转换，转换后两者可能是等价的。因此，在基于成本的模型中，EXISTS 并不比IN 更有效。

当然，对于早期的优化器或基于规则的优化器，IN 和EXISTS 的性能可能不一致。此时，网络上广泛流传的计划也可能是正确的。但现在基于规则的优化器已经很少使用了，基本上都使用基于成本的优化器。