网络，这4个部
分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。
2.1 系统处理器(CPU)
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的
过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就
足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。
2.2 内存(RAM)
为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL
Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多
能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相
Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由
Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL
Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。
Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内
存多于可用的物理内存时，会降低SQL Server的性能。
这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它
软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存
。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的
法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需
要32MB+100用户*100KB＝42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说
2.3 磁盘子系统
设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨
论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统
的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下：
(1)控制器高速缓存。
(2)总线主板上有处理器，可以减少对系统CPU的中断。
(3)异步读写支持。
(4)32位RAID支持。
(5)快速SCSI?2驱动。
(6)超前读高速缓存(至少1个磁道)。
3 检索策略
在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应
用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查
询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引；第2
3.1 SQL Server优化器
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交
的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE
和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字
符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用
图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供
SQL Server的优化通过3个阶段完成：查询分析、索引选择、合并选择。
1.查询分析 在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“<>”的子句。因为“<>”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。
2.索引选择
对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用
于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为
是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原
来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所
有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否
符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。
所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为
(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的
索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，
较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储
和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的
(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须
做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。
(4)对1个经常被更新的列建立索引，会严重影响性能。
(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些
(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可
(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子
(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快
(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“
ORDER 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子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。
4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式
生成索引选择。例如：
paycheck * 12>36000 or substring(lastname,1,1)=“L”
如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改
写上面的条件表达式为：
paycheck<36000/12 or lastname like “L%”
5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为
6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表
中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作
表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。 所以应该注意RAM中或磁
盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的
4 性能优化的其他考虑
上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也
很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选
项也不同程度上影响了SQL Server的性能。
影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实
的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优
化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。
分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。
2.1 系统处理器(CPU)
根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的
过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就
足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。
2.2 内存(RAM)
为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL
Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多
能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相
Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由
Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL
Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。
Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内
存多于可用的物理内存时，会降低SQL Server的性能。
这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它
软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存
。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的
法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需
要32MB+100用户*100KB＝42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说
2.3 磁盘子系统
设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨
论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统
的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下：
(1)控制器高速缓存。
(2)总线主板上有处理器，可以减少对系统CPU的中断。
(3)异步读写支持。
(4)32位RAID支持。
(5)快速SCSI?2驱动。
(6)超前读高速缓存(至少1个磁道)。
3 检索策略
在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应
用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查
询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引；第2
3.1 SQL Server优化器
Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交
的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE
和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。
了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字
符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用
图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供
SQL Server的优化通过3个阶段完成：查询分析、索引选择、合并选择。
1.查询分析 在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“<>”的子句。因为“<>”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。
2.索引选择
对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用
于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为
是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原
来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所
有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否
符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。
所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为
(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的
索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作
(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，
较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储
和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的
(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须
做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。
(4)对1个经常被更新的列建立索引，会严重影响性能。
(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些
(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可
(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子
(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快
(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“
ORDER 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子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。
4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式
生成索引选择。例如：
paycheck * 12>36000 or substring(lastname,1,1)=“L”
如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改
写上面的条件表达式为：
paycheck<36000/12 or lastname like “L%”
5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为
6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表
中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作
表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。 所以应该注意RAM中或磁
盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的
4 性能优化的其他考虑
上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也
很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选
项也不同程度上影响了SQL Server的性能。
影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实
的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优
化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。