SQL Server优化如何通过3个阶段来完成?

数据库 SQL Server
以下的文章主要是介绍SQL Server优化如何通过3个阶段来完成,查询分析、索引选择以及合并选择。下面就是文章的主要内容的具体介绍,望大家借鉴。

以下的文章主要是介绍SQL Server优化如何通过3个阶段来完成,查询分析、索引选择以及合并选择。以下就是正文的主要内容的详细内容的介绍,望会大家以后的学习或是工作中带来很大的帮助。

1.查询分析

在查询分析阶段,SQL Server优化器查看每一个由正规查询树代表的子句,并判断它是否能被优化。SQL Server优化一般会尽量优化那些限制扫描的子句。例如,搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句,如含有SQL不等关系符“<>”的子句。

因为“<>”是1个排斥性的操作符,而不是1个包括性的操作符,所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可SQL Server优化的子句时,执行计划用表扫描来访问查询的这个部分,对于查询树中可优化的SQL Server子句,则由优化器执行索引选择。

2.索引选择

对于每个可优化的子句,优化器都查看数据库系统表,以确定是否有相关的索引能用于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时,这个索引才被认为是有用的。因为索引是根据列的顺序构造的,所以要求匹配是精确的匹配。

对于分簇索引,原来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据,就像想在电话本中查找所有姓为某个姓氏的条目一样,排序基本上没有什么用,因为你还是得查看每一行以确定它是否符合条件。如果1个子句有可用的索引,那么优化器就会为它确定选择性。

所以在设计过程中,要根据查询设计准则仔细检查所有的查询,以查询的优化特点为基础设计索引。

(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说,每页上能存放较多的索引行,而且索引的级别也较少。所以,缓存中能放置更多的索引页,这样也减少了I/O操作。

(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比,较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引,因为它们将增加存储和维护的开支。对于复合索引、组合索引或多列索引,SQL Server优化器只保留最重要的列的分布统计信息,这样,索引的第1列应该有很大的选择性。

(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能,因为所有的索引都必须做相应的调整。另外,所有的分页操作都被记录在日志中,这也会增加I/O操作。

(4)对1个经常被更新的列建立索引,会严重影响性能。

(5)由于存储开支和I/O操作方面的原因,较小的自组索引比较大的索引性能更好一些。但它的缺点是要维护自组的列。

(6)尽量分析出每一个重要查询的使用频度,这样可以找出使用最多的索引,然后可以先对这些索引进行适当的优化。

(7)查询中的WHERE子句中的任何列都很可能是个索引列,因为优化器重点处理这个子句。

(8)对小于1个范围的小型表进行索引是不划算的,因为对于小表来说表扫描往往更快而且费用低。

(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“ORDER BY”命令中用到的列上有分簇索引,那么就不会再生成1个工作表了,因为行已经排序了。“GROUP BY”命令则一定产生1个工作表。

(10)分簇索引不应该构造在经常变化的列上,因为这会引起整行的移动。在实现大型交易处理系统时,尤其要注意这一点,因为这些系统中数据往往是频繁变化的。

3.合并选择

当索引选择结束,并且所有的子句都有了一个基于它们的访问计划的处理费用时,优化器开始执行合并选择。合并选择被用来找出一个用于合并子句访问计划的有效顺序。为了做到这一点,优化器比较子句的不同排序,然后选出从物理磁盘I/O的角度看处理费用***的合并计划。

因为子句组合的数量会随着查询的复杂度极快地增长,SQL Server查询优化器使用树剪枝技术来尽量减少这些比较所带来的开支。当这个合并选择阶段结束时,SQL Server优化查询优化器已经生成了1个基于费用的查询执行计划,这个计划充分利用了可用的索引,并以最小的系统开支和良好的执行性能访问原来的数据。

3.2 高效的查询选择

从以上查询优化的3个阶段不难看出,设计出物理I/O和逻辑I/O最少的方案并掌握好处理器时间和I/O时间的平衡,是高效查询设计的主要目标。也就是说,希望设计出这样的查询:充分利用索引、磁盘读写最少、***效地利用了内存和CPU资源。

以下建议是从SQL Server优化器的优化策略中总结出来的,对于设计高效的查询是很有帮助的。

1.如果有独特的索引,那么带有“=”操作符的WHERE子句性能***,其次是封闭的区间(范围),再其次是开放的区间。

2.从数据库访问的角度看,含有不连续连接词(OR和IN)的WHERE子句一般来说性能不会太好。所以,优化器可能会采用R策略,这种策略会生成1个工作表,其中含有每个可能匹配的执行的标识符,优化器把这些行标志符(页号和行号)看做是指向1个表中匹配的行的“动态索引”。优化器只需扫描工作表,取出每一个行标志符,再从数据表中取得相应的行,所以R策略的代价是生成工作表。

3.包含NOT、<>、或! =的WHERE子句对于SQL Server优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的,而不是包括性的,所以在扫描整个原来数据表之前无法确定子句的选择性。

4.限制数据转换和串操作,优化器一般不会根据WHERE子句中的表达式和数据转换式生成索引选择。例如:

 

  1. paycheck * 12>36000 or substring(lastname,1,1)=“L” 

如果该表建立了针对paycheck和lastname的索引,就不能利用索引进行优化,可以改写上面的条件表达式为:

 

  1. paycheck<36000/12 or lastname like “L%” 

5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的,例外的情况是定义为储备过程输入参数的变量。

6.如果没有包含合并子句的索引,那么优化器构造1个工作表以存放合并中最小的表中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作表的生成和随后的分族索引的生成,这个过程叫REFORMATTING。

所以应该注意RAM中或磁盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外,如果这些类型的操作是很常见的,那么把tempdb放在RAM中对于提高性能是很有好处的。

4 性能优化的其他考虑

上面列出了影响SQL Server优化的一些主要因素,实际上远不止这些。操作系统的影响也很大,在Windows NT下,文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选项也不同程度上影响了SQL Server的性能。

影响性能的因素是如此的多,而应用又各不相同,找出1个通用的SQL Server优化方案是不现实的,在系统开发和维护的过程中必须针对运行的情况,不断加以调整。事实上,绝大部分的优化和调整工作是在与客户端独立的服务器上进行的,因此也是现实可行的。

【编辑推荐】

  1. SQL Server合并复制性能的提高有哪些方案?
  2. SQL Server Compact中的DLL文件与工具
  3. SQL Server数据库在安装时的注意事项
  4. SQL Server 2005数据库安装实例演示
  5. SQL Server 2000全文检索的使用方案描述

 

责任编辑:佚名 来源: 计世网
相关推荐

2011-08-12 14:51:31

SQL ServerSET NOCOUNT

2010-07-26 17:36:44

SQL Server数

2010-07-20 11:35:41

避免SQL Serve

2010-07-23 10:54:09

优化SQL Serve

2009-04-03 15:14:42

微软优化SQL Server

2010-07-08 17:40:27

2023-03-10 08:37:33

预热优化PostgreSQL

2011-09-16 13:15:38

SQL Server优化

2009-05-06 10:14:21

中国联通WCDMA网络优化

2010-06-17 10:56:57

SQL Server数

2018-04-19 09:02:14

SQL ServerSQL性能优化

2011-07-11 13:16:19

SQL TraceSQL Profile

2010-07-14 10:24:25

SQL Server获

2010-07-15 16:42:32

数据库引擎

2021-10-13 06:49:13

SQL Server优化

2015-04-14 15:24:01

SQL ServerOLAPDBA

2009-05-14 13:18:50

SQL Server代理任务微软

2010-05-20 16:09:07

优化IIS

2010-07-09 09:54:34

SQL Server字

2010-07-13 17:31:56

SQL Server恢
点赞
收藏

51CTO技术栈公众号