数据库性能优化

 

Ø    前言

性能调整的目标是通过最大限度地降低网络通信、减少磁盘 I/O 和 CPU 时间，使所有用户处理的吞吐量都达到最大，从而为每一次查询提供可接受的响应时间。这一目标的实现，必须建立在对应用程序的要求进行彻底分析、及对数据逻辑和物理结构有深刻的理解基础之上，并需要对数据库的竞争使用而造成的性能消长进行评估和协调。

 

Ø    应用系统设计

在应用系统的设计中，要着重考虑以下几点：

一．合理使用索引

索引是数据库中重要的数据结构，它的根本目的就是提高查询效率。索引的使用要恰到好处，其使用原则如下：

●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。

●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。

●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。

●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。

例：

表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况：

1.在date上建有一非个群集索引

select count(*) from record where date >

'19991201' and date < '19991214'and amount >2000 (25秒)

select date,sum(amount) from record group by date (55秒)

select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)

分析：

date上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。

2.在date上的一个群集索引

select count(*) from record where date >'19991201' and date < ‘19991214' and amount >2000 （14秒）

select date,sum(amount) from record group by date （28秒）

select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）

分析：

在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。

3.在place，date，amount上的组合索引

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000 （26秒）

select date,sum(amount) from record group by date （27秒）

select count(*) from record where date >'19990901' and place in ('BJ', 'SH')（< 1秒）

分析：

这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。

4.在date，place，amount上的组合索引

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000(< 1秒)

select date,sum(amount) from record group by date （11秒）

select count(*) from record where date >'19990901' and place in ('BJ','SH')（< 1秒）

分析：

这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。

5.小结：

缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说：

①.有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，可考虑建立群集索引；

②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；

③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

 

二．避免或简化排序

应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：

●索引中不包括一个或几个待排序的列；

●group by或order by子句中列的次序与索引的次序不一样；

●排序的列来自不同的表。

为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。

 

三．消除对大型表行数据的顺序存取

在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。

还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：

SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：

SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001

UNION SELECT ＊ FROM orders WHERE order_num=1008

这样就能利用索引路径处理查询。

 

四．避免相关子查询

一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

 

五．避免困难的正规表达式

MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”

即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。

另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。

 

六．使用临时表加速查询

把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。

例如：

SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0

AND cust.postcode>“98000” ORDER BY cust.name

如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：

SELECT cust.name，rcvbles.balance，……other columns

FROM cust，rcvbles WHERE cust.customer_id = rcvlbes.customer_id

AND rcvblls.balance>0 ORDER BY cust.name INTO TEMP cust_with_balance

然后以下面的方式在临时表中查询：

SELECT ＊ FROM cust_with_balance WHERE postcode>“98000”

临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。

注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。

临时表 － 在 tempdb 中的临时表会导致查询进行大量 I/O 操作和磁盘访问，临时表会消耗大量资源。
内嵌视图 －使用内嵌视图取代临时表。内嵌视图只是一个可以联接到 FROM 子句中的查询。如果只需要将数据联接到其他查询，则可以试试使用内嵌视图，以节省资源。

建立的临时表尽量使用局部临时表，而非全局临时表。临时表在使用完以后，请及时删除。避免不必要的内存冗余。

 

七．用排序来取代非顺序存取

非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。

 

八．不充份的连接条件

LEFT JOIN 消耗的资源非常之多，因为它们包含与 NULL（不存在）数据匹配的数据。在某些情况下，这是不可避免的，但是代价可能非常高。LEFT JOIN 比 INNER JOIN 消耗资源更多，所以如果您可以重新编写查询以使得该查询不使用任何 LEFT JOIN，则会得到非常可观的回报。

加快使用 LEFT JOIN 的查询速度的一项技术涉及创建一个 TABLE 数据类型，插入第一个表（LEFT JOIN 左侧的表）中的所有行，然后使用第二个表中的值更新 TABLE 数据类型。此技术是一个两步的过程，但与标准的 LEFT JOIN 相比，可以节省大量时间。一个很好的规则是尝试各种不同的技术并记录每种技术所需的时间，直到获得用于您的应用程序的执行性能最佳的查询。
DECLARE @tblMonths TABLE (sMonth VARCHAR(7))

例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况：

select sum(a.amount) from account a,card b where a.card_no = b.card_no（20秒）

将SQL改为：

select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）

分析：

在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为：

外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O

在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：

外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O

可见，只有充份的连接条件，真正的最佳方案才会被执行。

小结：

1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。

2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就可以看到连接顺序、使用何种索引的信息；想看更详细的信息，需用sa角色执行dbcc(3604,310,302)。

 

九．存储过程

我们平时每次向SQL2000发送的SQL脚本，都需要通过服务器编译后执行。存储过程则不需要编译就能直接执行，因此速度可以更快！

建立存储过程的原则：

在频繁使用的SQL语句建议使用存储过程。

存储过程尽量使用SQL自带的返回参数，而非自定义的返回参数。

减少不必要的参数，避免数据冗余。

 

十．游标

想要依次遍历一个记录集的唯一方法就是使用系统游标，同样要注意的是，在使用完成之后及时关闭和销毁游标对象释放他用到的资源。并且不在万不得已的情况下，不要随意使用游标，因为他会占用较多的系统资源，尤其是对于大并发量的情况下，很容易使得系统资源耗尽而崩溃。

 

十一．事务处理

在很多的情况下，我们在存储过程中都会遇到需要同时操作多个表的情况，这时候就需要避免在操作的过程中由于意外而造成的数据的不一致性。这时候就需要将操作多个表的操作放入到事务中进行处理。但是需要注意的是，不能在事务中使用return语句强行退出，这样会引发事务的非正常错误，不能保证数据的一致性。并且，一旦将多个处理放入事务当中，系统的处理速度会有所降低，所以应当将频繁操作的多个可分割的处理过程放入到多个存储过程当中，这样会大大提高系统的响应速度，但是前提是不违背数据的一致性。

 

Ø    硬件策略

操作系统性能的好坏直接影响数据库的使用性能，如果操作系统存在问题，如CPU过载、过度内存交换、磁盘I/O瓶颈等，在这种情况下，单纯进行数据库内部性能调整是不会改善系统性能的。我们可以通过Windows NT的系统监视器(System Monitor)来监控各种设备，发现性能瓶颈。重点注意以下几点：

一．CPU

CPU一种常见的性能问题就是缺乏处理能力。系统的处理能力是由系统的CPU数量、类型和速度决定的。如果系统没有足够的CPU处理能力，它就不能足够快地处理事务以满足需要。我们可以使用System Monitor确定CPU的使用率，如果以75%或更高的速率长时间运行，就可能碰到了CPU瓶颈问题，这时应该升级CPU。但是升级前必须监视系统的其他特性，如果是因为SQL语句效率非常低，优化语句就有助于解决较低的CPU利用率。而当确定需要更强的处理能力，可以添加CPU或者用更快的CPU替换。

 

二．内存

SQL Server可使用的内存量是SQL Server性能最关键因素之一。而内存同I/O子系统的关系也是一个非常重要的因素。例如，在I/O操作频繁的系统中，SQL Server用来缓存数据的可用内存越多，必须执行的物理I/O也就越少。这是因为数据将从数据缓存中读取而不是从磁盘读取。同样，内存量的不足会引起明显的磁盘读写瓶颈，因为系统缓存能力不足会引起更多的物理磁盘I/O。可以利用System Monitor检查SQL Server的Buffer Cache Hit Ratio计数器，如果命中率经常低于90%，就应该添加更多的内存。

 

三．I/O子系统

I/O子系统发生的瓶颈问题是数据库系统可能遇到的最常见的同硬件有关的问题。配置很差的I/O子系统引起性能问题的严重程度仅次于编写很差的SQL语句。I/O子系统问题是这样产生的，一个磁盘驱动器能够执行的I/O操作是有限的，一般一个普通的磁盘驱动器每秒只能处理85次I/O操作，如果磁盘驱动器超载，到这些磁盘驱动器的I/O操作就要排队，SQL的I/O延迟将很长。这可能会使锁持续的时间更长，或者使线程在等待资源的过程中保持空闲状态，其结果就是整个系统的性能受到影响。解决I/O子系统有关的问题也许是最容易的，多数情况下，增加磁盘驱动器就可以解决这个性能问题。

 

Ø    系统参数设置

一．内存管理

l      服务器内存选项

使用两个服务器内存选项 min server memory 和 max server memory 重新配置缓冲池中SQL SERVER实例所使用的内存量（以 MB 为单位）。

默认情况下，SQL Server 能够可用系统资源动态改变它的内存需求。min server memory 的默认设置为 0，max server memory 的默认设置为 2147483647。可以为 max server memory 指定的最小内存量为 4 MB。

当 SQL Server 动态使用内存时，它要求系统定期地检测可用的物理内存数量。SQL Server 根据服务器活动增大或收缩高速缓冲存储器，以使可用物理内存保持在 4 MB 到 10 MB 之间。这就避免了Windows 2000 换页。如果有较少可用内存，则 SQL Server 将内存释放给Windows 2000，后者通常继续使用可用列表。如果有更多可用内存，则 SQL 200 将内存再提交到高速缓冲存储器。SQL SERVER 仅在其工作负荷需要更多的内存时才增加高速缓冲存储器的内存；处于休眠状态的服务器不增大其高速缓冲存储器。

允许 SQL SERVER 动态使用内存是推荐使用的配置；然而，可以手工设置内存选项并且可以禁止 SQL SERVER 动态使用内存的能力。在设置 SQL SERVER 使用的内存量之前，应确定适当的内存设置，方法是从全部物理内存中减Windows 2000 以及 SQL SERVER 的任何其它实例所需要的内存（以及其它系统使用的内存，如果该计算机不为 SQL SERVER 专用）。这就是可以分配给 SQL SERVER 使用的最大内存量。

l      手工设置内存选项

手工设置 SQL Server 内存选项有两种主要方法：

第一种方法，设置 min server memory 和 max server memory 为同一数值。该数值与分配给 SQL SERVER 的固定内存量相对应。

第二种方法，把 min server memory 和 max server memory 数量设置到一个范围段内。这种方法在系统或数据库管理员希望配置 SQL Server 实例，使其适应在同一台计算机上运行的其它应用程序的内存需求时很有用。

min server memory 保证了 SQL SERVER 实例使用的最小内存量。SQL SERVER 启动时不立即分配 min server memory 中所指定的内存量。但是，当内存使用由于客户端负荷而达到该值后，SQL SERVER 将无法从已分配的缓冲池中释放内存，除非减少 min server memory 值。

max server memory 则可防止 SQL Server 使用多于指定数量的内存，这样剩余的可用内存可以快速运行其它应用程序。SQL Server 启动时不立即分配 max server memory 中所指定的内存。内存使用随 SQL Server 的需要而增长，直到达到 max server memory 中所指定的值。SQL Server 无法超过该内存使用值，除非增加 max server memory 值。

在应用程序启动和 SQL Server 释放内存之间将有一个较短的时间延迟，使用 max server memory 可以避免该延迟，从而可以提高其它应用程序的性能。仅当与 SQL Server 共享同一台服务器的新应用程序在启动时显示有问题时，才设置 min server memory。最好让 SQL Server 使用全部可用的内存。

如果手工设置内存选项，应确保适当地设置用于复制的服务器。如果服务器是一个远程分发者或者是一个出版者/分发者的组合，则必须为它分配至少 16 MB 的内存。

理想情况下，在不引起系统交换页面到磁盘的前提下，应尽可能多地分配内存给 SQL Server。该值因系统不同而有很大差别。例如，在一个 32 MB 系统中，分配 16 MB 给 SQL Server可能是合适的；在一个 64 MB 系统中，则可能适合分配 48 MB。

指定的内存数量必需满足 SQL Server 的静态内存（核心开销、打开的对象、锁等等）以及数据缓存（亦称高速缓存）的需要。

如有必要，在系统监视器（在 Windows NT 4.0 中为性能监视器）中使用统计功能帮助调整内存值。应该只有在您添加或减少内存，或者改变系统使用方式时改变这些值。

l      虚拟内存管理器

Windows 2000 随时提供一个 4 GB 的虚拟地址空间，其中较低的 2 GB 地址空间对于每个进程是专用的，并可由应用程序使用。较高的 2 GB 地址由系统保留使用。Windows NT Server 企业版为每个 Microsoft Win32® 应用程序提供 4 GB 的虚拟地址空间，其中较低的 3 GB 地址空间是每个进程专用的，并可由应用程序使用。较高的 1 GB 地址由系统保留使用。

4-GB 的地址空间由 Windows NT V虚拟内存管理器（VMM）映射到可用的物理内存空间。取决于硬件平台的支持，可用的物理内存可以高达 4 GB。

Win32 应用程序（如 SQL Server）只能识别虚拟（或称逻辑）地址，而不是物理地址。在给定的某一时刻一个应用程序使用多少物理内存由可用的物理内存和 VMM所决定。应用程序不能直接控制物理内存。

像Windows 2000 这样的虚拟地址系统允许过度提交物理内存，这使虚拟内存和物理内存的比率大于 1:1。因此，较大的程序可以运行在具有不同物理内存配置的计算机上。然而应用比组合平均工作集大得多的虚拟内存可能导致较差的性能。

SQL Server 可以将内存锁定为工作集。因为内存被锁定了，当运行其它应用程序时可能出现内存不足的错误。如果出现内存不足的错误，则可能是分配给 SQL Server 的内存太多。set working set size选项（通过 sp_configure 或 SQL Server 企业管理器设置) 可以使锁定内存为工作集功能失效。默认情况下，set working set size 选项处于禁用状态。

手工配置给 SQL Server 多于物理内存数量的虚拟内存会导致性能较低。而且，必须考虑Windows 2000 操作系统的内存需求（大约 12 MB，因应用程序的开销而略有不同）。当 SQL Server 的配置参数上调时，系统的开销可能也会增长，因为Windows 2000 需要更多的常驻内存来支持附加的线程、页表等。允许 SQL Server to 动态使用内存可以避免内存相关的性能问题。

min server memory 和 max server memory 是高级选项。如果要使用 sp_configure 系统存储过程改变该选项，必须把 show advanced options 设置为 1，该选项立即生效（无需停止并重新启动服务器）。

二．线程活动

在Windows 2000 中，进行中的活动（线程）可以在处理器间迁移，每次迁移都刷新处理器高速缓存。在系统负荷繁重的情况下，指定一个处理器运行某特定的线程可以提高系统性能，方法是减少处理器缓存重新加载的次数。处理器和线程之间的关联称为处理器亲和力。

利用 affinity mask 选项可以在系统负荷过重时提高对称多处理器 (SMP) 系统（多于 4 个处理器）的性能。可以将线程与特定的处理器相关联，并指定 MiSQL要使用的处理器。也可以使 SQL Server 的活动在已由Windows 2000 操作系统指派了特定工作负荷的处理器之外的处理器上运行。

 

三．游标

使用 cursor threshold 选项指定游标集的行数，游标键集在该游标集中异步产生。如果将 cursor threshold 设为 –1，则所有游标键集将同步产生，这对于小游标集很有用。如果将 cursor threshold 设为 0，则所有游标键集异步产生。如果 cursor threshold 为其它值，查询优化器将比较游标集中所期望的行数和游标阈值的设置值，如果前者大于后者，则游标键异步产生。不要把 cursor threshold 值设得太低，因为小结果集以同步方式创建会更好一些。

当游标为某个结果集生成一个键集时，查询优化器估计将为该结果集返回的行数。如果查询优化器估计返回行的数目大于该阈值，则游标异步产生，使用户能够在游标继续填充的同时从中提取行。否则，游标同步产生，查询将等待所有的行返回。

查询优化器估计键集中行数的准确性取决于游标中各表统计的当前值。

 

四．锁

使用 locks 选项设置可用锁的最大数量，以限制SQL Server 用于锁的内存量。默认设置为 0，即允许 SQL Server 根据系统需要动态分配和收回锁。

当服务器以locks的设置为 0 启动，锁管理器分配 SQL Server 可用内存的2%给锁结构初始池当锁池耗尽时，系统会分配另外的锁，动态锁池的内存分配不能多于 SQL Server分配到的内存的40%。

通常情况下，如果锁需要的内存比当前可用的内存少，而更多的服务器内存是可用的（max server memory 上限还没有达到），则 SQL Server 动态分配内存满足锁的需求。然而，如果内存分配导致操作系统级的换页（例如，如果另一个应用程序与 SQL Server 实例运行于同一台计算机上并使用该计算机上的内存），则将分配更多的锁空间。

建议让 SQL Server 动态使用锁。然而，可以设置 locks 从而覆盖 SQL Server 动态分配锁资源的能力。如果SQL Server显示已经没有可用的锁的消息，请增大该选项的值。由于每一个锁都需要消耗内存（每一个锁需 96 字节），增加该值将增加整个服务器对内存的需要。

locks 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把 show advanced options 设置为1，该选项在停止并重新启动服务器后生效。

 

五．索引

使用 fill factor 选项指定当使用现有数据创建新索引时，Microsoft® SQL Server™ 应使每一页填满的程度。由于 SQL Server 必须在填充时花费时间分割这些页面，所以 fill factor 百分比会影响系统性能。

fill factor 百分比仅在创建索引时使用。这些页面都不可能被维护在任何特定的饱满水平上。

fill factor 的默认值为 0；其有效值是从 0 到 100。fill factor 的值为 0 并不表示页面的填满程度为 0%。类似于 fill factor 设置为 100 的情况，SQL Server 在 fill factor 值为 0 时，会用页面全部为数据的页来创建聚集索引，用页面全部为数据的叶子页来创建非聚集索引。与 fill factor 设置为 100 的情况不同的是，SQL Server 在索引树的高层级别上预留空间。很少有理由去改变 fill factor 的默认值，因为可以使用 CREATE INDEX 命令来覆盖它。

较小的 fill factor 值将导致 SQL Server 以不饱满的页面创建新索引。例如，将 fill factor 值设置为10 对于想在一个最终将保持较少数据的表上创建索引是合适的。越小的 fill factor 值将导致每一个索引占用更多的存储空间，但同时也允许以后可不进行页面拆分进行插入操作。

如果设置 fill factor 值为 100，SQL Server 以100% 的饱满度创建聚集和非聚集索引。设置 fill factor 的值为 100 仅对只读表是合适的，因为数据从来不被添加到此类表中。

fill factor 是一个高级选项。如果要用 sp_configure 系统存储过程改变该设置，必须把当 show advanced options 设置为 1 时仅能更改 fill factor，该选项在停止并重新启动服务器后生效。

 

六．数据查询

当没有足够的内存运行查询时，大量占用内存的查询（如那些涉及排序和哈希操作的查询）将排队等待。查询在一段时间之后将会超时，该时间或者由 SQL Server 计算（估计查询耗费时间的 25 倍），或者由查询等待选项设定的非负数值确定。

query wait 选项可以设定一个查询在超时前等待所需资源的时间（以秒为单位，范围从 0 到2147483647）。如果使用默认值 –1 或指定 –1，则超时时间通过计算得到，是预计查询成本的 25 倍。

query governor cost limit 选项用来指定一个查询所能运行的最高时间限制。查询成本是指在特定的硬件配置中，执行查询所耗费的估计时间（以秒为单位）。

如果为该选项指定一个非零、非负的数值，则查询调控器将不允许执行估计成本超过该值的查询。指定为 0（默认值）则将关闭查询调控器。在这种情况下，所有查询都允许运行。

七．最大吞吐量

SQL安装程序自动配置 Windows  2000 以使网络应用程序的吞吐量最大。这使得服务器可以接纳更多的连接。虽然对SQL建议使网络应用程序的吞吐量最大，但可以更改该设置。

如果安装了全文检索功能，则必须设置Windows 2000配置以使网络应用程序的吞吐量最大，并且不能更改。

八．配置服务器任务调度

如果打算从本地客户端（与服务器运行在同一台计算机上的客户端）连接到SQL SERVER，可通过设置服务器以相同的优先级运行前台和后台应用程序来改进处理时间。作为在后台运行的应用程序，SQL Server 便可与在前台运行的其它应用程序具有相同的优先级。

Ø    优化备份和还原性能

SQL SERVER 提供几种方法提高备份及还原操作的速度：

l      使用多个备份设备使得可以将备份并行写入所有设备。同样，可以将备份并行从多个设备还原。备份设备的速度是备份吞吐量的一个潜在瓶颈。使用多个设备可以按使用的设备数成比例提高吞吐量。

 

l      使用数据库备份、差异数据库备份和事务日志备份的组合，可以将故障恢复所需的时间减到最少。差异数据库备份可以减少必须应用于恢复数据库操作的事务日志量。这种方法通常比创建完整数据库备份快。

 

Ø    总结

其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。因此找出一个通用的优化方案是很困难的，只能是在系统开发和维护的过程中针对运行的具体情况，不断加以调整。

看完了上面的这些技巧，相信对您或多或少会有些帮助，也希望通过上面的一些经验。总结，可以使得您在应用SQL Server的时候，有意识的可以避免一些弯路。