SQL Server中TOP子句可能导致的问题以及解决办法

原文:SQL Server中TOP子句可能导致的问题以及解决办法

简介

     在SQL Server中,针对复杂查询使用TOP子句可能会出现对性能的影响,这种影响可能是好的影响,也可能是坏的影响,针对不同的情况有不同的可能性。

     关系数据库中SQL语句只是一个抽象的概念,不包含任何逻辑。很多元数据都会影响执行计划的生成,SQL语句本身并不作为生成执行计划所参考的元数据(提示除外),但TOP关键字却是直接影响执行计划的一个关键字,因此在某些情况下使用TOP会导致性能受到影响,下面我们来看集中不同的情况。

 

单表情况

    对于单表查询(这里的所说的单表指的是不包含视图、表值函数的物理单表)来说,存在TOP基本不会对性能产生影响,如果在SQL Server中加入了TOP,那么TOP本身可以看作是一个查询提示,意味着告诉优化器“返回结果只有N行”。我们看一个简单的例子,如图1所示:

图1.指定TOP关键字的单表执行计划

 

    由图1执行计划对比可以看出,对于有索引支撑的单表查询来说,使用TOP子句往往可以提升性能,此时TOP N的行数的N则提示查询优化器该查询返回N行,而不是使用统计信息中的数据分布,此时TOP N对于查询优化器来说是合理的。

    但有些时候Grant Memory(每次执行计划生成时会预估所需的内存,如果预估内存小于执行内存,则会spill to tempdb,对性能产生非常大的影响,由于每一个版本预估内存的公式变化极大,因此不在此详细解释了)不准会产生非常高的性能影响。在开始谈这点,之前,我们先谈两个操作符:

Sort

    Sort操作符是非常通用的排序操作符,在执行计划中可能会出现在多个地方,比如Merge Join之前,由于Order By导致的等。该算法非常通用,可以对非常大的结果集进行排序,该操作符是阻塞式(意味着排序结束之前数据无法流动到下一个操作符),并且需要大量内存和CPU资源。该操作符还有一个问题是当Grant Memory不足时,需要TempDB辅助完成排序,因此有极大的性能开销。

Top N Sort

    TOP N Sort是适应小场景,专门针对少量查询的排序算法。对于只选择几条数据来说,对于整个结果集进行排序成本过于高昂,因此TOP N的算法是首先取第一条数据,与其他数据进行对比,看是否最大(或最小),再取第二条数据对比,依次类推,直到找到前N条数据。该算法如果行数较小,则相比SORT操作符性能提升明显,但如果N值过大,则由于下述原因该算法不合适:

1.该算法不支持spill to tempdb,导致无法承载太大的结果集。

2.该算法需要遍历N次,如果N过大,则成本过高。

 

    对于SQL Server来说,这个N是否过大的阈值是100。下面我们来看一个例子,测试数据和代码如代码清单1所示。

CREATE TABLE TestTop
(id INT,sortkey INT,SOMEvalue CHAR(1000))
 
  DECLARE @i INT =1
  WHILE @i<300000
  BEGIN
  INSERT INTO TestTop VALUES(@i,@i,'a')
  SET @i=@i+1
  END
  
  CREATE CLUSTERED INDEX PK_id ON TestTop(id)
  --test 1
  SELECT TOP(100) * FROM TestTop
  ORDER BY sortkey
  --test 2
  SELECT TOP(101) * FROM TestTop
  ORDER BY sortkey

代码清单1.测试数据与测试代码

 

    第一个测试为TOP 100,正好使用TOP N Sort的算法,第二个测试为TOP 101,只能使用普通Sort的算法,如图2所示。

图2.TOP 101的SORT需要更多内存,从而导致内存授予不足spill to tempdb

 

    我们再来看执行时间,由于spill to tempdb的存在,那么执行时间如图3所示。

图3.相差非常大的执行时间

    从图3可以看出,执行时间相差非常大。

   因此对于TOP的使用来说,尽量使用TOP 100以内的数值。

 

多表情况

    由于TOP语句带有对优化器基数估计的提示功能,因此多表查询时在极端情况下可能导致行数低估从而影响性能。

    比如下面如图4的示例查询

图4.使用TOP 1的表接连查询

 

    在这种情况下,由于TOP1的存在使得查询优化器使用1作为估计行数,与实际的行数差异巨大,因此对于这种情况,使用TOP反而可能导致成本更高(虽然我们看到图4中估计的是0%对比100%,但实际差异巨大),更高的原因不仅仅是优化器估计为1,因为Loop Join只要发现1条就可以立刻结束,但上面例子中由于过滤条件选择性过低,导致找到第一条数据的随机查找过多(loop join内表循环是随机IO),成本如图5所示。

图5.使用TOP反而导致性能下降

 

    根本原因是由于估计行数只有1行,大部分情况下这一行

    对于上面这种情况来说,我们通常可以有下面集中解决办法:

1.使用提示,由于我们知道这是由于实际行数远大于估计行数导致,因此我们可以尝试使用hash join,forcescan等提示。

2.增加where条件,使得返回行数具有更高的选择性。

3.不使用TOP1,而使用TOP 10以上的数字,让估计行数变大,比如图5中的查询我们由TOP1 变为TOP10,那么执行计划则变为如图6所示。

图6.TOP 10的执行计划

 

    这是由于当行数少时,LOOP JOIN可以更快返回有限的行数,相当于对表加了FAST N提示,但行数增多时,优化器更倾向使用MERGE或者HASH完成操作,在上面返回行极多(选择性低)的极端情况下,会拥有更好的性能,结果如图7所示。

图7.特殊情况下TOP10相比TOP1有更好性能。

 

    因此结合单表的例子,推荐使用TOP关键字时,数字在10到100之间。

 

小结

    本文介绍了TOP关键字在单表和多表条件下可能对执行计划产生的影响,进而影响了查询计划。TOP影响执行计划主要是下面两个方面:

  • 内存授予
  • 估计行数

    因此在特殊情况下调优TOP语句时,可以根据实际情况考虑本文的建议。

时间: 2024-11-03 09:33:49

SQL Server中TOP子句可能导致的问题以及解决办法的相关文章

SQL Server中事务日志已满的原因以及解决办法

  错误描述:数据库的事务日志已满.若要查明无法重用日志中的空间的原因 ,请参阅sys.databases 中的 log_reuse_wait_desc 列 .   首先引入一下事务日志的概念(来自百度百科):   事务日志是一个与数据库文件分开的文件.它存储对数据库进行的所有更改,并全部记录插入.更新.删除.提交.回退和数据库模式变化.事务日志还称作前滚日志或重做日志.   事务日志是备份和恢复的重要组件,也是使用 SQL Remote 或 [复制代理] 复制数据所必需的.   在缺省情况下,

SQL SERVER中什么情况会导致索引查找变成索引扫描

SQL Server 中什么情况会导致其执行计划从索引查找(Index Seek)变成索引扫描(Index Scan)呢? 下面从几个方面结合上下文具体场景做了下测试.总结.归纳.   1:隐式转换会导致执行计划从索引查找(Index Seek)变为索引扫描(Index Scan) Implicit Conversion will cause index scan instead of index seek. While implicit conversions occur in SQL Ser

SQL Server中提前找到隐式转换提升性能的办法

原文:SQL Server中提前找到隐式转换提升性能的办法     http://www.cnblogs.com/shanksgao/p/4254942.html 高兄这篇文章很好的谈论了由于数据隐式转换造成执行计划不准确,从而造成了死锁.那如果在事情出现之前发现了这类潜在的风险岂不是更好?     那么我们来看一个简单的例子,如代码清单1所示.   1: SELECT * 2: FROM HumanResources.Employee 3: WHERE NationalIDNumber = 2

SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析

在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index Scan))呢?是否所有情况都是如此?又该如何优化呢? 下面我们通过一些简单的例子来分析理解这些现象.下面的实验环境为SQL SERVER 2008,如果在不同版本有所区别,欢迎指正.   堆表单索引 首先我们构建我们测试需要实验环境,具体情况如下所示: DROP TABLE TEST    CRE

sql server 安装出现“以前的某个程序安装...”的解决办法

笔者昨日在自己电脑上安装sql server 数据库,提示错误"以前的某个程序安装已在安装的计算机上创建挂起的文件操作.运行安装程序之前必须重新启动计算机"由于是第一次安装.就老老实实的按他的要求重启计算机然后在安装,接过还是提示这个错误.        笔者昨日在自己电脑上安装sql server 数据库,提示错误"以前的某个程序安装已在安装的计算机上创建挂起的文件操作.运行安装程序之前必须重新启动计算机"由于是第一次安装.就老老实实的按他的要求重启计算机然后在安

SQL Server无法收缩日志文件的原因分析及解决办法_MsSql

最近服务器执行收缩日志文件大小的job老是报错 我所用的一个批量收缩日志脚本 USE [master] GO /****** Object: StoredProcedure [dbo].[ShrinkUser_DATABASESLogFile] Script Date: 01/05/2016 09:52:39 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER PROC [dbo].[ShrinkUser_DATABASE

SQL Server无法收缩日志文件的原因分析及解决办法

最近服务器执行收缩日志文件大小的job老是报错 我所用的一个批量收缩日志脚本 USE [master] GO /****** Object: StoredProcedure [dbo].[ShrinkUser_DATABASESLogFile] Script Date: 01/05/2016 09:52:39 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER PROC [dbo].[ShrinkUser_DATABASE

php + sql server字段类型为ntext读取不完整的解决办法

php + mssql 让真让人痛苦.这些读 php 读 mssql 的 ntext 字段类型问题又来了:当 ntext 的内容过长时,居然读不完整. 在网上找了很久,都是说 php 读 ntext 出错的,但没发现我的页面出错,就郁闷了.后来才查到是说 php 默认最大只能读 4K 的内容,原来是我的内容超过了 4K.修改方法如下: 1.把 php 升级到 php5 .     还好,我的已经是 php5 了. 2.调整 php.ini 的参数,把 php 默认最大只能读 4K 改大一点.  

安装SQL Server 2008时 总是不断要求重启电脑的解决办法_mssql2008

window运行:regedit然后找到HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager/PendingFileRenameOperations右键 PendingFileRenameOperations  删除这一项即可!