[转]sql优化--in和exists效率

标签: | 发表时间:2014-01-14 23:21 | 作者:zeo112140
出处:http://blog.csdn.net/zeo112140

系统要求进行SQL优化,对效率比较低的SQL进行优化,使其运行效率更高,其中要求对SQL中的部分in/not in修改为exists/not exists

修改方法如下:

in的SQL语句

SELECT id, category_id, htmlfile, title, convert(varchar(20),begintime,112) as pubtime 
FROM tab_oa_pub WHERE is_check=1 and 
category_id in (select id from tab_oa_pub_cate where no='1') 
order by begintime desc

修改为exists的SQL语句
SELECT id, category_id, htmlfile, title, convert(varchar(20),begintime,112) as pubtime 
FROM tab_oa_pub WHERE is_check=1 and 
exists (select id from tab_oa_pub_cate where tab_oa_pub.category_id=convert(int,no) and no='1') 
order by begintime desc

分析一下exists真的就比in的效率高吗?

    我们先讨论IN和EXISTS。
    select * from t1 where x in ( select y from t2 )
    事实上可以理解为:
    select * 
      from t1, ( select distinct y from t2 ) t2
     where t1.x = t2.y;
    ——如果你有一定的SQL优化经验,从这句很自然的可以想到t2绝对不能是个大表,因为需要对t2进行全表的“唯一排序”,如果t2很大这个排序的性能是不可忍受的。但是t1可以很大,为什么呢?最通俗的理解就是因为t1.x=t2.y可以走索引。但这并不是一个很好的解释。试想,如果t1.x和t2.y都有索引,我们知道索引是种有序的结构,因此t1和t2之间最佳的方案是走merge join。另外,如果t2.y上有索引,对t2的排序性能也有很大提高。
    select * from t1 where exists ( select null from t2 where y = x )
    可以理解为:
    for x in ( select * from t1 )
    loop
       if ( exists ( select null from t2 where y = x.x )
       then 
          OUTPUT THE RECORD!
       end if
    end loop
    ——这个更容易理解,t1永远是个表扫描!因此t1绝对不能是个大表,而t2可以很大,因为y=x.x可以走t2.y的索引。


    综合以上对IN/EXISTS的讨论,我们可以得出一个基本通用的结论:IN适合于外表大而内表小的情况;EXISTS适合于外表小而内表大的情况。


我们要根据实际的情况做相应的优化,不能绝对的说谁的效率高谁的效率低,所有的事都是相对的.

in和exists的区别与SQL执行效率分析

本文对in和exists的区别与SQL执行效率进行了全面整理分析……

最近很多论坛又开始讨论in和exists的区别与SQL执行效率的问题,
本文特整理一些in和exists的区别与SQL执行效率分析

SQL中in可以分为三类:

  1、形如select * from t1 where f1 in ('a','b'),应该和以下两种比较效率

  select * from t1 where f1='a' or f1='b'

  或者 select * from t1 where f1 ='a' union all select * from t1 f1='b'

  你可能指的不是这一类,这里不做讨论。

  2、形如select * from t1 where f1 in (select f1 from t2 where t2.fx='x'),

  其中子查询的where里的条件不受外层查询的影响,这类查询一般情况下,自动优化会转成exist语句,也就是效率和exist一样。

  3、形如select * from t1 where f1 in (select f1 from t2 where t2.fx=t1.fx),

  其中子查询的where里的条件受外层查询的影响,这类查询的效率要看相关条件涉及的字段的索引情况和数据量多少,一般认为效率不如exists。

  除了第一类in语句都是可以转化成exists 语句的SQL,一般编程习惯应该是用exists而不用in,而很少去考虑in和exists的执行效率.

in和exists的SQL执行效率分析

  A,B两个表,

  (1)当只显示一个表的数据如A,关系条件只一个如ID时,使用IN更快:

  select * from A where id in (select id from B)

  (2)当只显示一个表的数据如A,关系条件不只一个如ID,col1时,使用IN就不方便了,可以使用EXISTS:

  select * from A

  where exists (select 1 from B where id = A.id and col1 = A.col1)

  (3)当只显示两个表的数据时,使用IN,EXISTS都不合适,要使用连接:

  select * from A left join B on id = A.id

  所以使用何种方式,要根据要求来定。

  这是一般情况下做的测试:

  这是偶的测试结果:

  set statistics io on 
  select * from sysobjects where exists (select 1 from syscolumns where id=syscolumns.id) 
  select * from sysobjects where id in (select id from syscolumns ) 
  set statistics io off 

 (47 行受影响)

  表'syscolpars'。扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 2 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  表'sysschobjs'。扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  (1 行受影响)

  (44 行受影响)

  表'syscolpars'。扫描计数 47,逻辑读取 97 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  表'sysschobjs'。扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  (1 行受影响)

  set statistics io on 
  select * from syscolumns where exists (select 1 from sysobjects where id=syscolumns.id) 
  select * from syscolumns where id in (select id from sysobjects ) 
  set statistics io off 


  (419 行受影响)

  表'syscolpars'。扫描计数 1,逻辑读取 10 次,物理读取 0 次,预读 15 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  表'sysschobjs'。扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  (1 行受影响)

  (419 行受影响)

  表'syscolpars'。扫描计数 1,逻辑读取 10 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  表'sysschobjs'。扫描计数 1,逻辑读取 3 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  (1 行受影响)

  测试结果(总体来讲exists比in的效率高):

  效率:条件因素的索引是非常关键的

  把syscolumns 作为条件:syscolumns 数据大于sysobjects

  用in

  扫描计数 47,逻辑读取 97 次,

  用exists

  扫描计数 1,逻辑读取 3 次

  把sysobjects作为条件:sysobjects的数据少于syscolumns

  exists比in多预读 15 次


  对此我记得还做过如下测试:

  表

  test

  结构

  id int identity(1,1), --id主键\自增

  sort int, --类别,每一千条数据为一个类别

  sid int --分类id

  插入600w条数据

  如果要查询每个类别的最大sid 的话
select * from test a 
  where not exists(select 1 from test where sort = a.sort and sid > a.sid) 

select * from test a 
  where sid in (select max(sid) from test where sort = a.sort) 
的执行效率要高三倍以上。具体的执行时间忘记了。但是结果我记得很清楚。在此之前我一直推崇第二种写法,后来就改第一种了。


in和exists的sql执行效率分析,再简单举一个例子:
declare @t table(id int identity(1,1), v varchar(10))
insert @t select'a'
union all select'b'
union all select'c'
union all select'd'
union all select'e'
union all select'b'
union all select'c'
--a语句in的sql写法
select * from @t where v in (select v from @t group by v having count(*)>1)
--b语句exists的sql写法
select * from @t a where exists(select 1 from @t where id!=a.id and v=a.v) 
两条语句功能都是找到表变量@t中,v含有重复值的记录.

  第一条sql语句使用in,但子查询中与外部没有连系.

  第二条sql语句使用exists,但子查询中与外部有连系.

  大家看SQL查询计划,很清楚了.

  selec v from @t group by v having count(*)> 1

  这条Sql语句,它的执行不依赖于主查询主句(我也不知道怎么来描述in外面的和里面的,暂且这么叫吧,大家明白就行)

  那么,SQL在查询时就会优化,即将它的结果集缓存起来

  即缓存了

  v

  ---

  b

  c

  后续的操作,主查询在每处理一步时,相当于在处理 where v in('b','c') 当然,语句不会这么转化, 只是为了说明意思,也即主查询每处理一行(记为currentROW时,子查询不会再扫描表, 只会与缓存的结果进行匹配

  而

  select 1 from @t where id!=a.id and v=a.v

  这一句,它的执行结果依赖于主查询中的每一行.

  当处理主查询第一行时 即 currentROW(id=1)时, 子查询再次被执行 select 1 from @t where id!=1 and v='a' 扫描全表,从第一行记 currentSubROW(id=1) 开始扫描,id相同,过滤,子查询行下移,currentSubROW(id=2)继续,id不同,但v值不匹配,子查询行继续下移...直到currentSubROW(id=7)没找到匹配的, 子查询处理结束,第一行currentROW(id=1)被过滤,主查询记录行下移

  处理第二行时,currentROW(id=2), 子查询 select 1 from @t where id!=2 and v='b' ,第一行currentSubROW(id=1)v值不匹配,子查询下移,第二行,id相同过滤,第三行,...到第六行,id不同,v值匹配, 找到匹配结果,即返回,不再往下处理记录. 主查询下移.

  处理第三行时,以此类推...

  sql优化中,使用in和exist? 主要是看你的筛选条件是在主查询上还是在子查询上。

  通过分析,相信大家已经对in和exists的区别、in和exists的SQL执行效率有较清晰的了解。 
作者:zeo112140 发表于2014-1-14 15:21:53 原文链接
阅读:8 评论:0 查看评论

相关 [sql 优化 in] 推荐:

sql优化

- - 数据库 - ITeye博客
是对数据库(数据)进行操作的惟一途径;. 消耗了70%~90%的数据库资源;独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低;. 可以有不同的写法;易学,难精通. 固定的SQL书写习惯,相同的查询尽量保持相同,存储过程的效率较高. 应该编写与其格式一致的语句,包括字母的大小写、标点符号、换行的位置等都要一致.

sql 优化

- - SQL - 编程语言 - ITeye博客
转:数据库SQL优化大总结之 百万级数据库优化方案. 2014-07-18 09:33 雲霏霏 雲霏霏的博客 字号:. 网上关于SQL优化的教程很多,但是比较杂乱. 近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充. 网上关于SQL优化的教程很多,但是比较杂乱. 近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充.

索引SQL优化

- - SQL - 编程语言 - ITeye博客
(一)深入浅出理解索引SQL优化 (转).         实际上,您可以把索引理解为一种特殊的目录. 微软的SQL SERVER提供了两种索引:聚集索引(clustered index,也称聚类索引、簇集索引)和非聚集索引(nonclustered index,也称非聚类索引、非簇集索引). 下面,我们举例来说明一下聚集索引和非聚集索引的区别:  .

优化sql查询

- - 数据库 - ITeye博客
1、 首先要搞明白什么叫执行计划. 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案,这个方案是由查询优化器自动分析产生的,比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录,那查询优化器会选择“索引查找”方式,如果该表进行了归档,当前只剩下5000条记录了,那查询优化器就会改变方案,采用 “全表扫描”方式.

sql语句优化

- - 数据库 - ITeye博客
性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好. 对复杂的SQL语句,要设法对之进行简化. 1)不要有超过5个以上的表连接(JOIN). 2)考虑使用临时表或表变量存放中间结果.

SQL Server优化50法

- - CSDN博客推荐文章
虽然查询速度慢的原因很多,但是如果通过一定的优化,也可以使查询问题得到一定程度的解决.   查询速度慢的原因很多,常见如下几种:没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷).   I/O吞吐量小,形成了瓶颈效应.   没有创建计算列导致查询不优化.   内存不足网络速度慢查询出的数据量过大(可以采用多次查询,其他的方法降低数据量).

oracle sql 优化大全

- - Oracle - 数据库 - ITeye博客
最近遇到了oracle sql优化的问题,找了一下,发现这文章实在不错,跟大家分享一下,如果以后有什么新的改进也会继续补充的. 1     前言… 2 . 2     总纲… 2 . 3     降龙十八掌… 3 . 第一掌 避免对列的操作… 3 . 第二掌 避免不必要的类型转换… 4 . 第三掌 增加查询的范围限制… 4 .

Oracle SQL性能优化

- - 数据库 - ITeye博客
(1)      选择最有效率的表名顺序(只在基于规则的优化器中有效):. ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表. 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.

SQL Server优化50法

- - CSDN博客数据库推荐文章
  虽然查询速度慢的原因很多,但是如果通过一定的优化,也可以使查询问题得到一定程度的解决.   查询速度慢的原因很多,常见如下几种:. 没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷). I/O吞吐量小,形成了瓶颈效应. 查询出的数据量过大(可以采用多次查询,其他的方法降低数据量).

Oracle SQL性能优化

- - 数据库 - ITeye博客
(1)      选择最有效率的表名顺序(只在基于规则的优化器中有效):. ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表. 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.