SQLSERVR语句 in和exists哪个效率高本人测试证明

最近很多人讨论in和exists哪个效率高,今天就自己测试一下

我使用的是客户的数据库GPOSDB(已经有数据)

环境:SQLSERVER2005   Windows7

我的测试条件:两个表作连接根据VC_IC_CardNO字段,查出CT_InhouseCard表中的VC_IC_CardNO(卡号)在CT_FuelingData表中存在的记录

前提:某些人可能在SQL语句中有多个in,或者多个exists,这些情况很难测试效率的,因为大家的条件都不相同

例如下面两个SQL语句

 SELECT  OrderNo, SiteCode, AreaCode
FROM SchedulingProgram
WHERE AreaCode IN ( 'P', 'M' ) AND SiteCode IN ( SELECT SiteCode
FROM EnvBasicInfo
WHERE cityiD = 31 ) AND OrderNo NOT IN (
SELECT OrderNo
FROM KK_DeliveryinfoTmp )

上面SQL语句IN里面有IN和NOT IN

 SELECT  OrderNo, SiteCode, AreaCode
FROM SchedulingProgram
WHERE ( AreaCode IN ( 'P', 'M' ) AND SiteCode IN ( SELECT SiteCode
FROM EnvBasicInfo
WHERE cityiD = 31 )
) AND NOT EXISTS ( SELECT OrderNo
FROM KK_DeliveryinfoTmp
WHERE KK_DeliveryinfoTmp.OrderNo = SchedulingProgram.OrderNo )

上面的SQL语句IN里面又有NOT EXISTS

这样的情况很难测试同等条件下IN语句和EXISTS语句的效率

还有一个非SARG运算符

在《SQLSERVER企业级平台管理实践》的第424页里提到:

SQLSERVER对筛选条件(search argument/SARG)的写法有一定的建议

对于不使用SARG运算符的表达式,索引是没有用的,SQLSERVER对它们很难使用比较优化的做法。非SARG运算符包括

NOT、<>、NOT EXISTS、NOT IN、NOT LIKE和内部函数,例如:Convert、Upper等

所以当您的表中有索引并且SQL语句包含非SARG运算符,那么当测试SQL语句的执行时间的时候肯定相差很大,

因为有些SQL语句走索引,有些SQL语句不走索引


建表脚本

注意:两个表中都有索引!!

CT_FuelingData表

 USE [GPOSDB]
GO
/****** 对象: Table [dbo].[CT_FuelingData] 脚本日期: 08/24/2013 11:00:34 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[CT_FuelingData](
[RecordNO] [int] IDENTITY(1,1) NOT NULL,
[I_FD_StationNo] [int] NOT NULL,
[VC_FD_No] [varchar](50) NOT NULL,
[VC_FD_Cardno] [varchar](50) NOT NULL,
[I_FD_CardStatus] [int] NULL,
[LI_FD_CTC] [bigint] NOT NULL,
[I_FD_TypeCode] [int] NULL,
[I_FD_PumpID] [int] NOT NULL,
[VC_FD_OilType] [varchar](50) NULL,
[DE_FD_Volume] [decimal](18, 2) NULL,
[DE_FD_Price] [decimal](18, 2) NULL,
[DE_FD_Amount] [decimal](18, 2) NULL,
[I_FD_Point] [decimal](10, 2) NULL,
[D_FD_DateTime] [datetime] NOT NULL,
[VC_FD_GroupNo] [varchar](50) NULL,
[D_FD_GroupDate] [datetime] NULL,
[DE_FD_CardAmount] [decimal](18, 2) NULL,
[DE_FD_VolumeTotals] [decimal](18, 2) NULL,
[DE_FD_AmountTotals] [decimal](18, 2) NULL,
[I_FD_ISSend] [int] NULL,
[VC_FD_CardMoneyauthFile] [varchar](50) NULL,
[D_Month] [datetime] NULL,
CONSTRAINT [PK_CT_FuelingData_1] PRIMARY KEY CLUSTERED
(
[VC_FD_No] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] GO
SET ANSI_PADDING OFF

CT_InhouseCard表

 USE [GPOSDB]
GO
/****** 对象: Table [dbo].[CT_InhouseCard] 脚本日期: 08/24/2013 10:59:58 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[CT_InhouseCard](
[RecordNO] [int] IDENTITY(1,1) NOT NULL,
[VC_IC_CardNO] [varchar](50) NOT NULL,
[VC_IC_PhysicalNO] [varchar](50) NULL,
[I_IC_CardType] [int] NULL,
[VC_IC_UserName] [varchar](50) NULL,
[VC_IC_JobNO] [varchar](50) NULL,
[VC_IC_UserID] [varchar](50) NULL,
[VC_IC_Password] [varchar](50) NULL,
[DE_IC_CardAmount] [decimal](18, 2) NULL,
[DE_IC_AppendAmount] [decimal](18, 2) NULL,
[DE_IC_ConsumerAmount] [decimal](18, 2) NULL,
[I_IC_ISLost] [int] NULL,
[D_IC_UsedDateTime] [datetime] NULL,
[D_IC_UselifeDateTime] [datetime] NULL,
[I_IC_IssueStationNO] [int] NULL,
[VC_IC_IssuerNO] [varchar](50) NULL,
[D_IC_IssueDateTime] [datetime] NULL,
[D_IC_LastUpdateDateTime] [datetime] NULL,
[I_IC_CardStatus] [int] NULL,
[VC_IC_Remark] [varchar](256) NULL,
CONSTRAINT [PK_CT_InhouseCard] PRIMARY KEY CLUSTERED
(
[VC_IC_CardNO] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] GO
SET ANSI_PADDING OFF

测试脚本

因为这个是客户的数据库,本来里面已经有数据了,所以在测试之前先更新两个表的统计信息,以做到公正

 USE [GPOSDB]
GO
UPDATE STATISTICS CT_FuelingData
UPDATE STATISTICS CT_InhouseCard
GO

IN语句

 USE [GPOSDB]
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO
SET STATISTICS IO ON
GO
SET STATISTICS TIME ON
GO
SET STATISTICS PROFILE ON
GO
SELECT * FROM [dbo].[CT_FuelingData] WHERE [VC_FD_Cardno] IN (SELECT [VC_IC_CardNO] FROM [dbo].[CT_InhouseCard])

EXISTS语句

 USE [GPOSDB]
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO
SET STATISTICS IO ON
GO
SET STATISTICS TIME ON
GO
SET STATISTICS PROFILE ON
GO
SELECT *
FROM [dbo].[CT_FuelingData]
WHERE EXISTS ( SELECT [VC_IC_CardNO]
FROM [dbo].[CT_InhouseCard]
WHERE [dbo].[CT_FuelingData].[VC_FD_Cardno] = [dbo].[CT_InhouseCard].[VC_IC_CardNO] )

测试结果

IN语句

 SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 2 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 31 毫秒,占用时间 = 67 毫秒。 (167 行受影响)
表 'Worktable'。扫描计数 0,逻辑读取 0 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'CT_FuelingData'。扫描计数 1,逻辑读取 31 次,物理读取 1 次,预读 64 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'CT_InhouseCard'。扫描计数 1,逻辑读取 2 次,物理读取 1 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 (4 行受影响) SQL Server 执行时间:
CPU 时间 = 16 毫秒,占用时间 = 192 毫秒。

EXISTS语句

 SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。 SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒,占用时间 = 34 毫秒。 (167 行受影响)
表 'Worktable'。扫描计数 0,逻辑读取 0 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'CT_FuelingData'。扫描计数 1,逻辑读取 31 次,物理读取 1 次,预读 64 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'CT_InhouseCard'。扫描计数 1,逻辑读取 2 次,物理读取 1 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 (4 行受影响) SQL Server 执行时间:
CPU 时间 = 0 毫秒,占用时间 = 163 毫秒。

大家可以看到除了执行时间有一点差别,IO是一样的

因为数据量比较大,所以两个查询都用到了Worktable(中间表)来存储中间结果

IN语句的执行计划

EXISTS语句的执行计划

从执行计划可以看到两个SQL语句的开销都是一样的,而且大家都使用了右半连接(Right Semi Join)

至于什么是半连接(Semi-join)大家可以看一下这篇文章:SQL Join的一些总结

总结

从上面实际的执行来比较,,IN语句和EXISTS语句基本上都是一样的效率

如有不对的地方,欢迎大家来拍砖o(∩_∩)o

SQLSERVER语句 in和exists哪个效率高本人测试证明的更多相关文章

  1. in和exists哪个效率高本人测试证明

    in和exists哪个效率高本人测试证明 SQLSERVR语句 in和exists哪个效率高自己测试本人测试证明 最近很多人讨论in和exists哪个效率高,今天就自己测试一下 我使用的是客户的数据库 ...

  2. 为什么switch...case语句比if...else执行效率高

    在C语言中,教科书告诉我们switch...case...语句比if...else if...else执行效率要高,但这到底是为什么呢?本文尝试从汇编的角度予以分析并揭晓其中的奥秘. 第一步,写一个d ...

  3. 为什么说在使用多条件判断时switch case语句比if语句效率高?

    在学习JavaScript中的if控制语句和switch控制语句的时候,提到了使用多条件判断时switch case语句比if语句效率高,但是身为小白的我并没有在代码中看出有什么不同.去度娘找了半个小 ...

  4. 答:SQLServer DBA 三十问之一: char、varchar、nvarchar之间的区别(包括用途和空间占用);xml类型查找某个节点的数据有哪些方法,哪个效率高;使用存储 过程和使用T-SQL查询数据有啥不一样;

    http://www.cnblogs.com/fygh/archive/2011/10/18/2216166.html 1. char.varchar.nvarchar之间的区别(包括用途和空间占用) ...

  5. 为什么存储过程比sql语句效率高?

    存储过程经过预编译处理 而SQL查询没有 SQL语句需要先被数据库引擎处理成低级的指令 然后才执行 -------------------------------------------------- ...

  6. 关于in与exists的效率讨论

    关于in与exists的效率讨论1).select * from A where id in (select id from B)以上查询使用了in语句,in只执行一次,他查出B表的所有id字段并缓存 ...

  7. SQL点滴35—SQL语句中的exists

    原文:SQL点滴35-SQL语句中的exists 比如在Northwind数据库中有一个查询为 SELECT c.CustomerId,CompanyName FROM Customers c WHE ...

  8. mysql查询语句in和exists二者的区别和性能影响

    mysql中的in语句是把外表和内表作hash 连接,而exists语句是对外表作loop循环,每次loop循环再对内表进行查询.一直大家都认为exists比in语句的效率要高,这种说法其实是不准确的 ...

  9. MySQL IN和EXISTS的效率问题,以及执行优化

    网上可以查到很多这样的说法: 如果查询的两个表大小相当,那么用in和exists差别不大.如果两个表中一个较小,一个是大表,则子查询表大的用exists,子查询表小的用in: 例如:表A(小表),表B ...

随机推荐

  1. XMLFeedSpider例子

    from scrapy import log from scrapy.contrib.spiders import XMLFeedSpider from myproject.items import ...

  2. MongoDB 分页查询的方法及性能

    最近有点忙,本来有好多东西可以总结,Redis系列其实还应该有四.五.六...不过<Redis in Action>还没读完,等读完再来总结,不然太水,对不起读者. 自从上次Redis之后 ...

  3. Youth -Samuel Ullman

    Samuel Ullman(塞缪尔.厄尔曼) Youth is not a time of life,it is a state of mind;青春不是年华,而是心境: it is not a ma ...

  4. mac apache 2.4的配置

    开启vhost 文件 命令行输入 vim /etc/apache2/httpd.conf 找到把前边的# include /private/etc/apache2/extra/httpd-vhost. ...

  5. IDE-Sublime【3】-配置Node.js开发环境

    一.下载Nodejs插件,下载地址为https://github.com/tanepiper/SublimeText-Nodejs,解压到当前文件夹,改名为Nodejs 二.打开Sublime Tex ...

  6. 深入理解定时器系列——被誉为神器的requestAnimationFrame

    与setTimeout和setInterval不同,requestAnimationFrame不需要设置时间间隔.这有什么好处呢?为什么requestAnimationFrame被称为神器呢?本文将详 ...

  7. bzoj3110树套树

    wa一片,最后一个T,终于心碎了... 为什么没人告诉我要开longlong 为什么所有人都说没有负数 #include<cstdio> #include<algorithm> ...

  8. [BZOJ4197][Noi2015]寿司晚宴

    4197: [Noi2015]寿司晚宴 Time Limit: 10 Sec  Memory Limit: 512 MBSubmit: 412  Solved: 279[Submit][Status] ...

  9. 还原后缀名为.bak的数据库备份文件

    1.打开SQL Server Management Studio,随便右击击一个数据库选择任务-->还原-->数据库 4.在弹出来的窗口中的源选项中选择设备-->点选择设备--> ...

  10. css 大话盒子模型

    什么是盒子模型? CSS中, Box Model叫盒子模型(或框模型),Box Model规定了元素框处理元素内容(element content).内边距(padding).边框(border) 和 ...