再论一下in,exists,join

SQL优化--使用 EXISTS 代替 IN 和 关联查询（inner join) 昨天的这篇文章提及到的一些问题，在这里我做一下自己的测试，测试结果以微软标准Adventureworks数据库内数据结构为准。

 

测试语句：

 

set statistics io on
set statistics time on
select a.* from Production.Product a inner join Production.ProductModel b
on (a.ProductModelID = b.ProductModelID)

select a.* from Production.Product a where exists (select 'X' from Production.ProductModel b
where a.ProductModelID = b.ProductModelID)

select a.* from Production.Product a where a.ProductModelID in (select b.ProductModelID from Production.ProductModel b)

 

测试统计：

 

SQL Server 分析和编译时间: 
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
SQL Server 分析和编译时间: 
   CPU 时间 = 15 毫秒，占用时间 = 63 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

(9440 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Product'。扫描计数 1，逻辑读取 474 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'ProductModel'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 63 毫秒，占用时间 = 1984 毫秒。

(9440 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Product'。扫描计数 1，逻辑读取 474 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'ProductModel'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 78 毫秒，占用时间 = 1780 毫秒。

(9440 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Product'。扫描计数 1，逻辑读取 474 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'ProductModel'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 109 毫秒，占用时间 = 1366 毫秒。
SQL Server 分析和编译时间: 
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

 

执行计划

 

可以看到无论是查询计划还是统计IO，都是一样的。

这都是优化器的功劳，并不存在哪个谓词就好些，除非你的测试环境是2000以下。