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以下。
当前标签: sql优化
MSSQL优化之 1.3 存储架构之 页 Keep Walking 2008-08-17 22:02 阅读:13816 评论:35
MSSQL优化之 1.1 存储架构之文件和文件组 Keep Walking 2008-08-08 16:22 阅读:5146 评论:12
再论一下in,exists,join Keep Walking 2008-08-06 09:04 阅读:2896 评论:8
一个SQL大牛提的一个sql优化小测试 Keep Walking 2008-04-24 01:07 阅读:6111 评论:56
MSSQL调优日志
对 set statistics time on的两个执行时间权威解释
摘要: 今天在sqlservercentral上看到一个帖子，关于对set statistics time on输出两个cpu执行时间的解释（大牛的解释）：CPU time is how much time was spent by the CPU (or CPUs). Total time is how long it took from start to finish.For example, if...阅读全文
郁闷的一次调优
摘要: 前天给朋友调优，上的生产库用ssms远程连接测试，5个表的连接，每个表大小都在10万多的数据量，有几个是hash连接，比较费时，后来调优了几个索引后IO明显下降，但是在执行时间上一直没有明显下降，实在是没辙了，调优到晚上一点钟，睡觉，第二天继续，最后怀疑是因为网络问题，让朋友上的远程桌面生产库直接执行，一秒以内！晕死了，原来是因为网络传输问题导致在我机器上的执行时间延长！不过几个表的连接比较难控制...阅读全文
最详细的临时表，表变量的对比
摘要: 迄今为止，我认为最详细的临时表和表变量的对比。阅读全文
再论一下in,exists,join
摘要: SQL优化--使用 EXISTS 代替 IN 和 关联查询（inner join) 昨天的这篇文章提及到的一些问题，在这里我做一下自己的测试，测试结果以微软标准Adventureworks数据库内数据结构为准。阅读全文
一个小trick，如何快速给现有表添加一个自增字段
摘要: http://www.mssqltips.com/tip.asp?tip=1467
大家可以看看这篇文章，讲到的是如何给一个现有表更快速的添加一个自增字段阅读全文
大家可以看看这篇文章，讲到的是如何给一个现有表更快速的添加一个自增字段阅读全文
关于上一个sql优化测试的部分知识
摘要: 在上一个sql大牛提出的小测试中，优化的就是如何改变查询，来选择合适的连接方式。
mssql的连接方式有三种：
hash join
merge join
loop join
在这里，对比一下三种sql server连接方式如何选择。阅读全文
mssql的连接方式有三种：
hash join
merge join
loop join
在这里，对比一下三种sql server连接方式如何选择。阅读全文
一个SQL大牛提的一个sql优化小测试
摘要: 大家如果对SQL优化感兴趣的话,可以进来看看，挑战挑战。阅读全文
insert into 和select * into的性能比较
摘要: 有朋友说两者之间存在很大的性能差异，是由于数据库的日志模式不一样，simple和完整的会导致差异。
simple的select * into 不记日志。我自己也就来做了个测试。阅读全文
simple的select * into 不记日志。我自己也就来做了个测试。阅读全文
MSSQL调优实战一 乱建聚集索引的后果
摘要: 今天调优某电信的大型数据库，是一个日志型的表，其中有个自增列字段和时间（时间是每个小时小时来的，每个小时有大概23万条记录），以及点击次数等日志信息，数据量在4000万以上，sp_spaceused使用了大概2G多的磁盘空间。整个表没有分区。整个表都是插入查询，没有更新操作。
阅读全文
阅读全文