IN只支持平等关系(或前面有NOT的不平等关系)。 它是=any / =some的同义词

select    * 
from      t1 
where     x in (select x from t2)
;

EXISTS支持不能用IN表示的不同类型的关系，例如-

select    * 
from      t1 
where     exists (select    null 
                  from      t2 
                  where     t2.x=t1.x 
                        and t2.y>t1.y 
                        and t2.z like '℅' || t1.z || '℅'
                  )
;

还有另一种说法——

exist和IN之间所谓的性能和技术差异可能是由于特定供应商的实现/限制/错误造成的，但很多时候它们只是由于缺乏对数据库内部结构的理解而产生的神话。

表的定义、统计数据的准确性、数据库配置和优化器的版本都会影响执行计划，因此也会影响性能指标。

哪个更快取决于内部查询获取的查询数量:

当您的内部查询获取数千行，那么EXIST将是更好的选择 当您的内部查询获取少量行时，那么IN将更快

EXIST对true或false进行评估，但在比较多个值。当你不知道记录是否存在时，你应该选择exist

Exists关键字计算true或false，而IN关键字比较相应子查询列中的所有值。 另一个Select 1可与Exists命令一起使用。例子:

SELECT * FROM Temp1 where exists(select 1 from Temp2 where conditions...)

但IN的效率较低，所以存在更快。

IN只支持平等关系(或前面有NOT的不平等关系)。 它是=any / =some的同义词

select    * 
from      t1 
where     x in (select x from t2)
;

EXISTS支持不能用IN表示的不同类型的关系，例如-

select    * 
from      t1 
where     exists (select    null 
                  from      t2 
                  where     t2.x=t1.x 
                        and t2.y>t1.y 
                        and t2.z like '℅' || t1.z || '℅'
                  )
;

还有另一种说法——

exist和IN之间所谓的性能和技术差异可能是由于特定供应商的实现/限制/错误造成的，但很多时候它们只是由于缺乏对数据库内部结构的理解而产生的神话。

表的定义、统计数据的准确性、数据库配置和优化器的版本都会影响执行计划，因此也会影响性能指标。

我发现使用EXISTS关键字通常非常慢(这在Microsoft Access中非常真实)。 相反，我以这样的方式使用join操作符: should-i-use-the-keyword-exists-in-sql

如果使用IN操作符，SQL引擎将扫描从内部查询中获取的所有记录。另一方面，如果我们使用EXISTS, SQL引擎将在找到匹配项后立即停止扫描过程。