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

 

测试语句:

 

 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 毫秒。

 

执行计划

再论一下in,exists,join

再论一下in,exists,join

 

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

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

 

相关文章:

  • 2022-12-23
  • 2022-12-23
  • 2022-12-23
  • 2021-09-24
  • 2021-11-15
  • 2022-12-23
  • 2021-09-16
  • 2022-12-23
猜你喜欢
  • 2021-10-11
  • 2022-12-23
  • 2021-11-08
  • 2021-09-18
  • 2022-12-23
  • 2021-07-25
  • 2022-12-23
相关资源
相似解决方案