Microsoft SQL Server 7.

0
性能调整指南

本文档中包含的信息代表了微软公司在出版时对所讨论问题的观点。由于正在
进行的开发工作的本身特性，且因为微软公司必须对正在变化的市场情况作出
反应，它不应当认为是微软公司的承诺，并且微软公司不对出版后的任何信息
的准确性作任何担保。
本文档仅用于资料用途。微软公司在本文档中，未作任何明示或暗示的担保。
© 1998 微软公司。保留所有权利。
Microsoft, ActiveX, BackOffice, the BackOffice logo, Fox Pro, PivotTable, Visual
Basic 和 Windows NT 是微软公司在美国和/或其他国家的注册商标或商标。
这里提到的其他产品和公司名称可能是其各自所有者的商标。
微软公司产品编号： 098-80705
 目录

观 众......................................................................................................................................3

介 绍......................................................................................................................................3
Microsoft SQL Server 6.x 版到 7.0 版的性能调整比较
...................................................................................................................................4

SQL Server 性能调 整原 则...............................................................................................5

评 价配置 期间 的 max async IO 选项..............................................................................6

消 耗 CPU 和 磁盘 I/O 资源的 组件................................................................................7

工作线程........................................................................................................................7
懒书写器(lazy Writer)...................................................................................................7
检查点............................................................................................................................8
日志管理器....................................................................................................................9
预读管理器....................................................................................................................9

磁 盘 I/O 性能....................................................................................................................10
磁盘传输率及 SQL Server 中的磁盘传输率.............................................................10
顺序与非顺序磁盘 I/O 操作.......................................................................................11
磁盘 I/O 传输率和 PCI 总线带宽..............................................................................12
RAID............................................................................................................................12
硬件 RAID 控制器自带高速缓存的影响...........................................................13
RAID 级别............................................................................................................14
普通 RAID 等级 .................................................................................................14
联机 RAID 扩充...................................................................................................15
性能监控器和 RAID............................................................................................15
Windows NT 软件方式 RAID..............................................................................16
并行磁盘 I/O ..............................................................................................................16

SQL Server 索引...............................................................................................................18
簇索引..........................................................................................................................19
非簇索引......................................................................................................................20
覆盖索引......................................................................................................................20
自动的覆盖索引或覆盖查询......................................................................................21
索引选择......................................................................................................................21
簇索引选择..................................................................................................................22
簇索引选择方案....................................................................................23
FILLFACTOR 和 PAD_INDEX.................................................................................24

SQL Server 性能调 整工 具..............................................................................................25

样本数据和工作负载..................................................................................................25
SQL Server 配置文件..................................................................................................25
使用带有索引调整向导（Index Tuning Wizard）的 SQL Server 配置文件. . .25

2
 分析 SQL Server 配置文件信息..........................................................................27
SQL Server 查询分析器..............................................................................................28
I/O 次数统计.........................................................................................................28
ShowPlan...............................................................................................................28
Showplan 输出示例.......................................................................................29
性能监控器（Performance Monitor）：...................................................................34
关键的性能监控器功能......................................................................................36
（物理或逻辑的）磁盘队列> 2..................................................................36
系统: 处理器队列长度> 2 (每个 CPU)......................................................36
硬分页 ­ Memory: Pages/Sec > 0 或者 Memory: Page Reads/Sec > 5......37
软分页­ Memory: Pages Faults/Sec > 0 .......................................................38
监控处理程序.......................................................................................................38
磁盘 I／O 次数计数器.........................................................................................39
性能监控器图形输出...........................................................................................40

其 他影响 性能 的因素 .....................................................................................................40

缓解网络交通和资源耗费..........................................................................................41
死锁..............................................................................................................................41
查询中要避免的语句..................................................................................................41
灵活的规范化..............................................................................................................42
分割视图......................................................................................................................42
复制和备份性能..........................................................................................................42
EMC 磁盘 I/O 调节方案.............................................................................................43

查 找更多 的信 息..............................................................................................................44

这份性能调整指南提供了一系列的信息，来帮助数据库管理员进行配置，以使
Microsoft® SQL Server™达到最优性能，并帮助他们搞清楚在 SQL Server 环境下造
观众 成性能损失的原因。本文档同时还提供了如何使用 SQL Server 索引，如何使用
SQL Server 工具，这些工具帮助分析 SQL Server 查询的 I/O 执行效率。

熟悉 Microsoft SQL Server 早期版本的数据库管理员可以从下面这张表中对 SQL 

Server 7.0 的性能有个大致的了解。
介绍

3
 Microsoft SQL Server 6.x 版到 7.0 版的性 能调 整比 较

SQL 6.x 需要考 虑的事项 SQL Server 7.0 相应的改进

在性能调整时需要考虑许多配置选项。 在 Microsoft SQL Server 7.0 版本中数据库机制实现了自配置、自调整、自
管理。 懒书写器（Lazy writer）与预读管理器（Read Ahead Manager）也
实现了自调整。max async IO 选项是唯一的 sp_configure 选项，仅在初始
化时、或者当工作于拥有巨大存储的服务器时使用这一选项。这种在调整
要求上的简化处理为数据库管理员节省了大量的时间，用节省下来的时间
可以去完成其它任务。
熟悉早期版本 SQL Server 的读者会注意到：数据库管理员不再需要配置过
多的 sp_configure 选项就可以得到较好的 SQL Server 性能。尽管数据库管
理员仍然可以手工配置和调整许多 SQL Server 早期版本的 sp_configure 选
项，我们还是建议他们使用 SQL Server 提供的所有缺省 sp_configure 选项
进行自动配置和调整。这样使 SQL Server 可以根据服务器的变化自动调整
数据库服务器的配置，例如运行于数据库服务器的 SQL Server 和其它应用
程序的 RAM 和 CPU 利用率。
有时需要手工调整懒书写器（lazy  与 Microsoft SQL Server 的早期版本不同， Microsoft SQL Server 7.0 可以
writer） 自动地配置和调整懒书写器（lazy writer）。你不再需要手工调整 free 
buffer 参数与 max lazywrite IO 参数。使用 SQL Server 7.0 性能监控对象
仍然可以监控空闲缓冲区和懒书写器（lazy writer ）I/O 的活动。
有时需要手工调整检查点。 Microsoft SQL Server 的早期版本中，还使用 recovery interval 选项来调整
检查点过程。当 recovery interval 选项被置为缺省值 0 时， Microsoft SQL 
Server 7.0 自动地监控和调整恢复时间间隔。只要在系统中没有超长运行时
间的事务处理，缺省配置会为所有数据库把恢复时间间隔保持在一分钟之
内。若想获取更多的资料，请参阅 SQL Server 7.0 联机帮助中的相关主题
和/或关键字：检查点、日志活动部分与定期故障恢复。
SQL Server 6.x 日志与数据页共享 RAM  Microsoft SQL Server 7.0 版明显改变了 SQL Server 的日志管理。SQL 
高速缓存。有时需要手工调整日志管 Server 7.0 日志管理器管理它自己的日志高速缓存。SQL Server 不再象早期
理器。 版本那样依赖 syslogs 表。将日志文件管理从数据高速缓存管理中分离出
来的做法，使这两部分的性能都得以提高。
SQL Server 日志管理器同时还能执行磁盘 I/O，其基本数据块的大小要大
于早期版本的数据块。增大的 I/O 数据块的大小和 I/O 的序列化帮助提高
其日志性能。SQL Server 7.0 将自动调整 SQL Server 日志管理器的性能。
不再需要手工调整 sp_configure 的 logwrite sleep 选项，因为 SQL Server 
7.0 已经根本不再提供这一选项。若想获取更多资料，请在 SQL Server 7.0
联机帮助中用关键字 logwrite sleep 查询。

4
对数据库服务器操作来说，分割页 Microsoft SQL Server 的早期版本中， 因为在分割页时需要重新计算索引页的
的开销颇大。 行数，因此需要大大调整 B 树索引页（当插入行填满了数据页或索引页时，
会发生分割页的情况）。SQL Server 7.0 对存储结构的改变使这个问题最小化。
非簇索引页（Nonclustered index pages）为没有簇索引的表（这样的表称之为
堆）采用固定 RID（行 ID­Row ID），有簇索引的表采用簇关键字。这样使插
入操作和分割页操作时对 B 树的维护工作大大减少了。总体影响是索引的维
护速度加快，这意味着在不影响数据修改性能的情况下，可以建立更多的非
簇索引。若想获取更多资料，请查阅 SQL Server 7.0 联机帮助的相关主题及/或
关键字：改善的结构、表结构及索引结构、分割页
SQL 跟踪（SQL Trace） Microsoft SQL Server 7.0 提供了 SQL Server 剖视器（Profiler），它代替了 SQL 
Server 6.5 中的 SQL 跟踪（ Trace） 工具。SQL Server 剖视器 提供了相似的、
但明显改善了的功能。
ISQL/W 在 SQL Server 7.0 中， SQL Server 查询分析器（Query Analyzer）代替了 SQL 
Server 早期版本的 ISQL/W 。
设备及分段 Microsoft SQL Server 7.0 引入文件和文件组 （files and filegroups），以此来代
替早期版本的设备模型和段模型。 这些文件和文件组为数据在磁盘和磁盘阵
列的合理分布提供了一种更便利的方法。若想获取更多资料，请查阅 SQL 
Server 7.0 联机帮助的相关主题：为文件组加索引，为文件组、文件及文件组
设置表，使用文件及文件组管理数据库变化。

Microsoft SQL Server 7.0 引进和改善了一
些调整 SQL Server 性能以达到最优性能
SQL Server 性能调整原则 的方法和工具。当你调整你的 SQL 
Server 时，请遵循以下原则：

• 让 SQL Server 完成大部分的调整工作。

Microsoft SQL Server 可以创建一个自动配置及自动调整的数据库服务器。充分
利用 SQL Server 提供的自动调整设置功能。这些设置帮助 SQL Server 保持以最
佳性能运行，甚至在用户装入内容不断变化或者查询内容不断变化的情况下也
能保持。

• RAM 是有限的资源。

对 RAM 高速缓存的管理是数据库服务器环境的一个整体特征。从 RAM 高速缓

存中存取数据比从磁盘中存取数据的速度要快得多，但是 RAM 是一种有限的资
源。如果数据页与索引页对数据 I/O 的要求可以降低到最低限度，那么这些页也
就可以在 RAM 中保存的时间更长一些。过多的不必要的数据信息和索引信息涌
入高速缓存会把有用页过快地挤出去。调整性能的重点就是减少 I/O，以使高速
缓存的利用率达到最高。

• 挑选好的索引。

为所有数据库查询保持最小 I/O 的一个关键性措施是：保证建立和维护适当的索

引。

• 评价磁盘 I/O 子系统性能。

物理磁盘子系统必须提供一个带有足够 I/O 处理功能的数据库服务器，可以在不

做磁盘查询操作的情况下直接运行它。过多的磁盘查询操作会导致性能的降低。
这篇文档描述了如何检测以及如何解决磁盘 I/O 的问题。

• 调整应用程序和查询程序

当数据库服务器处理由特定应用程序指定的、来自成百上千个连接点的服务请
求时，调整应用程序和查询程序变得非常重要。因为在典型情况下，是应用程

5
 序确定运行于数据库服务器上的 SQL 查询，所以应用程序开发者必须懂得 SQL
服务器的基本框架，以及如何充分利用 SQL Server 索引来使 I/O 最小化。

• 充分利用 SQL Server 剖视器（Profiler）及索引调整向导（Index Tuning Wizard）

SQL Server 剖视器（Profiler）可以用来监测 SQL Server 的工作量，并为其做日
志文件，然后可以将其递交给索引调整向导（Index Tuning Wizard） ，为实现
更好的性能而对索引重新进行调整。经常使用 SQL Server 剖视器和索引调整向
导可以帮助你优化索引，使 SQL Server 在查询工作改变的情况下仍能以较好的
性能工作。

• 利用 SQL Server 性能监视器(Performance Monitor)。

SQL Server 7.0 提供了一套修改过的性能监视器对象和计数器，它们可以用来为
监视和分析 SQL Server 操作提供有用的信息。这篇文档描述了性能监控器中一
些重要的计数器。

• 利用图形化显示方案（Graphical Showplan）和 SQL Server 查询分析器（Query 

Analyzer）

SQL Server 7.0 查询分析器引入了图形化显示方案，帮助分析在 Transact­SQL 查
询时出现的问题。SQL Server 查询分析器还包含 STATISTICS IO ，这是调整查
询功能的另一个重要的工具选项。

在 Microsoft SQL Server 
7.0 的初始化配置期间，
评价配 置期间的 max async IO 选项 如果需要的话，应对
max async IO 选项进行
评价和调整。

max async IO 选项的缺省值是 32，这对低级磁盘子系统来说已经足够。但如果数
据库服务器使用提供高速磁盘 I/O 传输的高级磁盘子系统——RAID，设置为 32 可
能就不够了，因为 RAID 子系统可以完成的磁盘同步传输请求数目远不止 32 个。
如果 SQL Server 写操作也要求更高的磁盘传输能力，那么 max async IO 选项的值
应该设置的更高一些。

max async IO 选项应当满足合适的值：在要求下一个检查点（基于期望恢复的性质）
之前，本检查点应该完成监测任务。而不是将这个选项值设置得过大，以至于使系
统被监测事件严重堵塞（磁盘排队是堵塞的一个特征，在本文的后续部分将做深入
的讨论）。

为运行在大磁盘子系统上的 SQL Servers 设置 max async IO 选项的一般性规则是：

将可用来同步的物理磁盘数乘以 2 或 3。然后观察性能监控器的磁盘活动标记和查
询结果。将此配置选项值设置得过高可能会造成这样的不良后果：检查点操作独占
其它 SQL Server I/O 操作（比如读操作）所要求的磁盘子系统带宽。

要设置 max async IO 选项值，可以执行 SQL Server 查询分析器（Query 

Analyzer）中的这个命令：sp_configure ‘max async io’， value， value 表示可以同
时提交的磁盘 I/O 请求的数目，这些 I/O 请求指的是 SQL Server 系统在检查点操作
时可以提交到 Windows®操作系统的请求，检查点操作按顺序把这些请求提交到物
理磁盘子系统。若想获取更多资料，请参阅本文档后面将提到的“磁盘 I/O 性能调
整”。这个配置选项是动态的，改变它的值可以立即有效，而不需要先关掉 SQL 
Server 然后再重新启动。

若想获取更多信息，请查阅 SQL Server 7.0 联机帮助：I/O 结构和 max async io 选项。

6
 仔细分析消耗系统资源的
Microsoft SQL Server 组件，
可以进一步优化 SQL Server
消耗 CPU 和磁盘 I/O 资源的组件 的性能。

工作线 程
Microsoft SQL Server 调整 Windows 操作系统线程池，来处理提交到数据库服务器
的 SQL Server 批处理命令。这些可以提供所有批处理命令服务的全体线程（称为
工作线程）是通过设置 sp_configure 的 max worker threads 选项来描述的。如果提
交的活动批处理命令数目大于 max worker threads 指定的数目，工作线程将被动态
提交的批处理命令连接（connections actively submitting  batches）共享。缺省设置
255 在大多数安装情况下工作得很好。

工作线程从 SQL Server 高速缓存中清除大多数不洁净的 8­KB 页面。工作线程异步

调度 I/O 操作，以达到最佳性能。

若想获取更多资料，请参考 SQL Server 7.0 联机帮助中的以下主题和/或关键字：使

用内存配置选项（Memory Configuration Options）、SQL Server 存储池（Memory 
Pool）、事务处理恢复（Transaction Recovery）、写优先处理日志（Write­Ahead 
Transaction Log）、清空缓存页面、写缓存页面（Freeing and Writing Buffer 
Pages）、SQL Server 线程，来优化服务器性能。

懒书写 器(lazy Writer)
SQL Server 懒书写器帮助产生空缓冲区，也就是一个不包含任何数据的 8­KB 高速
缓存页面。每当懒书写器把一个 8­KB 的缓冲区的内容存到磁盘时，它都会初始化
该缓冲页标识，以使其它数据可以写进该空缓冲区。懒书写器在磁盘 I/O 请求较少
的时候产生空缓冲区，为以后使用磁盘 I/O 资源作好准备，而且对其它 SQL Server 
操作产生的影响最小。

SQL Server 7.0 自动配置和管理空缓冲区的数目。监测 SQL Server: Buffer Manager 
­ Free Buffers 对象，保证空缓冲区的数目保持稳定。懒书写器调整缓冲区的数目，
使其满足用户对空缓冲区的要求。SQL Server: Buffer Manager ­ Free Buffers 对象
应该不会降低到 0，因为如果这样的话， SQL Server 懒书写器将总不能满足用户提
出的空闲缓冲区要求。

如果懒书写器不能保持空闲缓冲区资源的稳定，或者说不能始终保证可以提供空闲
缓冲区，这将意味着磁盘子系统的懒书写器不能始终提供磁盘 I/O 功能，那么需要
调整空闲缓冲区的数目（把这种空闲缓冲区数目减少的现象与任何其它确认是由磁
盘子系统问题引起的磁盘排队现象相比较）。解决磁盘排队问题的一种方法是为数
据库服务器磁盘子系统增加更多的物理磁盘（也称做 spindles ），为其提供更强的
I/O 处理能力。SQL Server: Buffer Manager – Lazy Writes/sec 对象表示的是懒书写
器写到磁盘的 8­KB 页面数。

在性能监控器中监控当前磁盘队列的长度，这是通过查看平均磁盘队列（Disk: 
Average Disk Queue ）或 当前磁盘队列（Current Disk Queue） 计数器的值（物
理的或逻辑的）得到的，以保证每一个与任何 SQL Server 动作相联系的物理磁盘的
队列长度都在小于 2。对于配置有硬件 RAID 控制器和磁盘阵列的数据库服务器，

7
 应该将磁盘计数器报告的数目（逻辑的或物理的）除以实际硬盘数目(这里的硬盘
数目可以从逻辑驱动器盘符得到，或者从 Windows NT® 磁盘管理器程序提供的物
理硬盘数得到)。因为 Windows 与 SQL Server 根本不考虑连到 RAID 控制器的实际
物理硬盘数目。而你却应当知道与 RAID 磁盘阵列控制器相连的驱动器数目，因为
这样才能明白性能监测器报告中的磁盘排队。

使用 max async IO 选项调整懒书写器磁盘 I/O 请求，它控制 8­KB 的磁盘写请求

（包括来自懒书写器、检查点、工作线程的请求）数目，这些写请求指的是 SQL 
Server 可以同时向 Windows 操作系统及依次向磁盘 I/O 子系统提交的请求。如果磁
盘排队的队列长度达到不可接收的地步，则减小 max async IO 选项的值。如果一
定要保持当前配置的 max async IO 选项值，则应向磁盘子系统添加更多的磁盘，
直到磁盘队列的长度可以接受为止 。

若想获取更多资料，请参考 SQL Server 7.0 联机帮助中的以下主题：清空缓冲区页、
写缓冲区页、写优先事务处理日志。

检查点
检查点（Checkpoint）操作将不洁净页写到 SQL Server 数据文件中。不洁净页指的
是在高速缓存中被修改的页。这些页被写到磁盘后，并没有从缓冲区中清除, 因此
用户仍然可以在高速缓存中直接读取或者修改这些页面，而不需要从磁盘中重新读
出来，这与懒书写器创建空闲缓冲区的方法不同。

检查点操作让工作线程和懒书写器做大部分清空不洁净页的工作。它会保持等待，
一直等到一个特别的检查点，才清空不洁净页。这样为工作线程和懒书写器提供了
更多的清空不洁净页的时间。SQL Server 文档中对这种额外等待时间的发生条件有
详细描述。检查点操作通过额外的检查点等待时间使 SQL Server 磁盘 I/O 活动在
较长时间段内达到均衡。

当有许多页涌入到高速缓存时，为使检查点工作更加有效，SQL Server 将数据页按
磁盘上的顺序排序。这种排序将尽量使磁盘臂移动距离最小，尽量允许检查点操作
利用顺序磁盘 I/O 的优势。检查点操作也可以直接向磁盘子系统提交异步 8­KB 字
节的磁盘 I/O 操作的请求。这样做可以使 SQL Server 更快地完成所需磁盘 I/O 请求
的提交，因为检查点操作不需要等待磁盘子系统做出数据实际已经写到磁盘的报告。

你应当观察与 SQL Server 数据文件相关的硬盘驱动器的排队情况，注意观察 SQL 

Server 是否发送了超出磁盘处理能力的过多磁盘 I/O 请求。如果是，那么应当增大
磁盘 I/O 的容量，提高磁盘子系统处理负载的能力。

使用 max async IO 选项可以改善检查点操作时过量不洁净页涌入的情况。
sp_configure 的 max async IO 选项控制特定 8­KB 高速缓存的数目，这些高速缓存
指的是检查点操作可以同时向 Windows 操作系统以及依次向磁盘 I/O 子系统提交的
缓存。如果磁盘队列的长度长到不可接受，那么减小 max async IO 选项的值。如
果 SQL Server 必须维持 max async IO 选项的当前值，那么为磁盘子系统增加磁盘
数目，直到磁盘队列的长度缩短到可以接受的水平。

如果你必须提高 SQL Server 执行检查点操作的速度，并且磁盘子系统有足够的能
力——可以在不引起磁盘排队等待就能处理增加的磁盘 I/O 操作，那么可以增大
max async IO 选项的值，以允许 SQL Server 提出更多的异步磁盘 I/O 请求。在你改
变 max async IO 选项值之后，请认真观察磁盘排队计数器。除了观察磁盘写队列，

8
还要观察磁盘读队列。如果 max async IO 选项对磁盘子系统来说设置得过高，检
查点操作可能会引起磁盘写 I/O 请求排队，这也将导致 SQL Server 读操作的堵塞。
性能监控器中的物理磁盘对象和逻辑磁盘对象提供了“平均磁盘读队列长度”
（Average Disk Read Queue Length ）计数器，它可以用来监测磁盘读 I/O 请求的
排队情况。如果磁盘读队列是由检查点操作引起的，你可以减小 max async IO 选
项的值，或者增加硬盘驱动器数目，以便同时处理检查点操作和读请求。

日志管 理器
象其它重要的关系数据库管理系统（RDBMS）产品一样， SQL Server 同样也保证
所有在数据库上执行的写操作（插入、修改、删除）在遇到异常中断情况时（例如：
电源掉电、磁盘损坏、数据中心失火等等），数据不会丢失。 SQL Server 的日志
处理可以保证恢复数据。在任何隐含的（单独的 SQL 查询）或者显式的（发出
BEGIN TRANSACTION, COMMIT 或 ROLLBACK 命令的事务处理）事务处理完成
之前， SQL Server 日志管理器一定要从磁盘子系统接收一个信号，表明所有与事
务处理相联系的修改数据都成功地写到了相关的日志文件中。这一规则保证了当服
务器遭遇突然停机，高速缓存上的内容还没有来得及写到数据文件中去，然后在重
新开机时，可以通过读取事务处理日志来恢复数据文件。填充数据缓存是检查点操
作或懒书写器的工作。服务器中断后读事务日志文件、进行 SQL Server 事务处理的
过程称之为恢复（recovery）。

因为当每个事务处理完成时， SQL Server 必须等待磁盘子系统完成对 SQL Server 

日志文件的 I/O 操作，因此包含 SQL Server 日志文件的磁盘必须有足够的磁盘 I/O
处理能力来处理期望的事务负载。

监测磁盘排队的方法对 SQL Server 日志文件和对 SQL Server 数据库文件的处理不

同。你可以使用性能监控器的计数器 SQL Server: Databases database instance : Log 
Flush Waits Times 以及 SQL Server: Databases database instance : Log Flush 
Waits/sec ，来查看在磁盘子系统上等待完成的日志书写器请求。

为获取最高性能，如果高速缓存控制器可以保证它里面的数据最终都将写到磁盘上，
甚至在电源掉电的情况下也能保证，那么你可以为 SQL Server 日志文件使用高速缓
存控制器。若想获取有关高速缓存控制器的更多资料，请参阅将在本文档后面部分
讨论的“硬件 RAID 控制器内嵌高速缓存的影响（Effect of On­Board Cache of 
Hardware RAID Controllers）”。

若想获取更多资料，请参考 SQL Server 7.0 联机帮助中的以下主题和/或关键字：事
务处理恢复，优化事务日志性能，日志管理器对象。

预读管 理器
Microsoft SQL Server 7.0 预读管理器是完全自配置与自调整的。预读管理器与 SQL 
Server 查询处理器紧密结合。SQL Server 查询处理器（Query Processor ）会识别那
些适合预读操作的情况。对较大表的扫描、大范围索引的扫描、查看 B 树中的簇索
引与非簇索引，这些情形都适合预读操作。预读操作每次读 64­KB I/O，相对于 8­
KB I/O 而言，为磁盘子系统提供了更高的磁盘流量。当需要从 SQL Server 检索大
量数据时，预读操作是最佳的方案。

预读管理器得益于使用更加简单、更加高效的索引分配表（Index Allocation Map –
IAM）存储结构。IAM 是 SQL Server 7.0 的新方法，用来记录范围（8 页 SQL 

9
 Server 数据信息或者索引信息，最大长度是 64 KB）的位置。IAM 是一个 8­KB 的
页面，使用位图这样的紧缩格式表示索引数据。紧缩格式的 IAM 页面的存取速度
很快，常用的 IAM 页面保存在高速缓存中。

预读管理器可以结合来自查询处理器的联合查询信息，创建多个读请求序列，并且
快速地检索所有范围的位置，这要从 IAM 页面中读取。序列化的 64­KB 磁盘读操
作提供了极好的磁盘 I/O 性能。

预读动作由 SQL Server: Buffer Manager ­ Readahead Pages 计数器监测。执行
DBCC PERFMON (IOSTATS)命令，你可以得到有关预读活动的更多信息。其中一
部分提供了 RA Pages Found in Cache 和 RA Pages Placed in Cache。如果页面已经被
哈希处理（应用程序先读到它，预读操作浪费一次读操作），那么它就是在高速缓
存中找到的页面。如果页面没有被哈希处理（顺利的完成预读），那么它是放在高
速缓存中的页面。

过多的预读操作会影响整体性能，因为它会在高速缓存中放入一些不必要的页面，
要求额外的 I/O 与 CPU 资源，而这些资源本可以用在其它地方。对这个问题的解决
是性能转换的目的，所有的 Transact­SQL 查询都将被转换，以使高速缓存中的页面
数达到最少。这包括对合适的任务使用合适的索引。为有效的范围扫描保存簇索引、
定义非簇状索引，以此来协助快速定位单独行，或者少数的若干行。

若想获取更多资料，请参考 SQL Server 7.0 联机帮助中的以下主题和/或关键字：读

页面、表和索引结构，堆结构， DBCC PERFMON，预读页。

当你配置一个只包含几兆字节数据的 SQL Server，而且此
SQL Server 不需要处理大量的读操作和写操作时，你不用过
磁盘 I/O 性能 多地考虑磁盘 I/O，也不用考虑使用多个硬盘来平衡 SQL 
Server I/O 的活动以达到最佳性能。但是，当你创建较大的
SQL Server 数据库，比如说包含数百兆字节的数据，并且/或者需要处理大量的读
和/或写操作时，你必须通过使用多个硬盘来平衡 SQL Server I/O 的活动，以配置
SQL Server 使其磁盘 I/O 性能达到最佳。

磁盘传 输率 及 SQL Server 中的磁 盘传 输率

数据库性能提高的一个重要表现是 I/O 性能的提高。除非 SQL Server 运行在一个拥
有足够大以至于可以保存全部数据库的计算机上，I/O 性能是由磁盘 I/O 子系统读
写处理 SQL Server 数据的速度来表示的。

典型的硬盘驱动器可以向 Windows 操作系统和 SQL Server 提供大约每秒 75 次非顺

序（随机）操作，以及每秒 150 次 顺序 I/O 操作。这些硬盘驱动器的传输速率大约
是每秒 40MB。数据库服务器的 I/O 传输速率很可能限制在每秒 75/150 次，而不是
每秒 40MB。得到以下的计算：

(每秒 75 次随机 I/O 操作) X (8­KB 的数据传输) = 每秒 600 KB

这一计算表明如果在一个硬盘驱动器上做严格的单独页面读写操作，你只会得到不
超过每秒 600 KB 的 I/O 处理能力。这远远低于所宣布的每秒 40 MB 的硬盘处理速
度。SQL Server 工作线程、检查点、及懒书写器都是用 8­KB 的传输块来执行 I/O
操作的。

(每秒 150 次顺序 I/O 操作) X (8­KB 的数据传输) = 每秒 1200 KB

10
这一计算标明如果在一个硬盘驱动器上做严格的顺序单独页面读写操作，你会得到
不超过每秒 1200 KB (1.2 MB)的处理能力。

(每秒 75 次随机 I/O 操作) X (64­KB 的数据传输) = 每秒 4800 KB (4.8 MB)

这一计算为假定全部都是随机 I/O 情况的预读显示了一种更坏的情形。然而即使在

完全随机 I/O 的情况下， 64­KB 的传输块大小也为磁盘提供了更好的磁盘 I/O 传输
率（每秒 4.8 MB），而不是单独页面（8­KB）传输率（每秒 0.6 MB 和 1.2 MB）。

(每秒 150 次顺序 I/O 操作) X (64­KB 的数据传输) = 每秒 9600 KB (9.6 MB)  

这一计算表明如果在一个硬盘上做严格的顺序读写操作，你会得到不超过每秒 9.6 
MB 的处理能力。这比随机 I/O 情况要好得多。SQL Server 预读管理器以 64­KB 的
传输率执行磁盘 I/O，安排读操作，因此预读（通常称为顺序化或按磁盘顺序）的
扫描是顺序执行的。尽管预读管理器顺序化执行 I/O 操作，页分离仍使得读操作非
顺序化。这是需要尽量消除和防止页分离的一个原因。

日志管理器按顺序填写日志文件，使之最大达到 32 KB。

顺序与 非顺 序磁 盘 I/O 操作
术语顺序与非顺序（随机）用来针对于硬盘驱动器的操作。一个单独的硬盘驱动器
由一组盘片组成，每一个盘片都通过一套读写头提供读写操作的服务，读写头可以
在盘片上移动，从盘片上读数据，或者向盘片写数据。记住有关硬盘驱动器和 SQL 
Server 的以下几点：

• 读/写头和与之相连的磁盘臂必须能移动，以定位到与 SQL Server 和 Windows 操

作系统要求内容相对应的盘片位置，并且进行相应的操作。如果数据在硬盘盘
片上以随机方式存储，那么硬盘移动磁盘臂和读写头一定会花费更多的时间定
位到所有要求的硬盘盘片的相应位置。而顺序存储的情形与此相反，所有要求
的数据存放在硬盘盘片的一个物理上连续的位置，这样磁盘臂和读写头可以移
动最小距离来执行必要的 I/O 磁盘操作。随机存储与顺序存储在时间上的差别是
显而易见的，随机存储大约只能达到 50ms，而顺序存储大约能达到 2­3 ms。这
些时间只是粗略的估计，对随机存储而言，存储时间还随着随机存储数据的分
布、硬盘盘片转速（RPM）、其它硬盘的物理特征的变化而变化。重要的一点
是顺序 I/O 操作对提高 SQL Server 性能很有好处。

• 典型的硬盘驱动器支持大约每秒 75 次随机 I/O 操作以及每秒 150 次顺序 I/O 操作。

读写 8 KB 字节所用的时间与读写 64 KB 字节所用的时间大致相同。在 8 KB 到
64 KB 的范围内，磁盘臂和读写头移动的时间主要是一次单独的磁盘 I/O 传输操
作。当多于 64KB 的 SQL 数据需要传输时，尽量执行 64­KB 字节的数据传输，
因为 64­KB 字节传输时间与 8­KB 字节的传输时间相同，这样每次传输可得到 8
倍于 8­KB 字节的传输量。预读管理器用 64­KB 的数据块处理磁盘操作（称为
SQL Server 范围）。日志管理器也用大尺寸的 I/O 块执行顺序写操作。通过更好
的利用预读管理器，以及从随机存取文件中分离 SQL Server 日志文件，你可以
提高 SQL Server 的性能。

若想获取关于物理硬盘驱动器的更多资料，请参阅 Compaq 的文献：“磁盘子系统
性能及其可变性”。参考本文档后面的“查阅更多资料”部分，将告诉你如何得到
此文献。

11
 磁盘 I/O 传输 率和 PCI 总线 带宽
一个典型的硬盘提供了大约每秒 40MB 或者每秒 75 次随机存储/150 次顺序存储的
最大传输率。所宣称的典型的 RAID 控制器大约有每秒 40MB 或每秒 2000 次的传
输率。所宣称的 PCI 总线有大约每秒 133MB 或更高的数据传输率。设备实际获得
的传输率与所宣称的通常会有一定的差别。你应当懂得如何通过这些传输率来决定
与每个 RAID 控制器相连的硬盘设备的数目，以及在不造成 I/O 瓶颈的情况下，可
以有多少个磁盘驱动器和 RAID 控制器与 PCI 总线相连。

我们在前面已经计算得到读写到一个硬盘驱动器的 SQL Server 数据的最大速率是
每秒 9.6 MB。假设 RAID 控制器可以处理每秒 40MB，你可以用 40 除以 9.6 大约得
到 4，便是连接到 RAID 控制器的硬盘驱动器的数目。这意味着当 SQL Server 只是
做 64KB 字节的顺序 I/O 操作时，与一个 RAID 控制器连接的硬盘驱动器的最大数
目是 4。类似的，我们计算 64KB 随机 I/O 的情况，从硬盘驱动器到控制器的最大
数据传输率是每秒 4.8MB。40MB 除以每秒 4.8MB，得到的结果是 8。这意味着在
随机 64­KB I/O 情况下，与一个控制器相连的硬盘驱动器的最大数目是 8。随机 8­
KB I/O 情况下 数据传输要求的驱动器数目最多。40 除以 0.6 得到结果 66，RAID
控制器连接 66 个硬盘驱动器可以使 8­KB 字节的读写达到饱和。当然这种情形是不
现实的，因为预读和写日志使用大于 8­KB 字节的传输尺寸，而且 SQL Server 也不
可能完全执行随机 I/O 操作。

你还可以通过查看磁盘每秒的操作次数，而不是每秒多少兆字节，来决定与 RAID
控制器相连的驱动器数目。如果硬盘驱动器可以有每秒 75 次的非顺序（随机）I/O
操作，那么 26 个硬盘驱动器一起工作原则上将产生每秒 2000 次的非顺序 I/O 操作，
或者说足够达到单个 RAID 控制器的最大处理能力。 同样，因为单个硬盘驱动器
可以处理每秒 150 次的顺序 I/O 操作，那么将需要 13 个硬盘驱动器一起工作以达到
每秒 2000 次的顺序 I/O 操作。

RAID 控制器和 PCI 总线 不象硬盘驱动器那样容易产生瓶颈现象。为说明这个问题，

假设有一组与 RAID 控制器相连的硬盘设备足够忙，达到每秒 40MB 的数据流量通
过 RAID 控制器。下面要考虑的是最多可以有多少个 RAID 控制器可以与 PCI 总线
相连，而不至于引起 PCI 总线瓶颈的危险。为得到一个大致的的估计，用 PCI 总线
的 I/O 处理能力除以 RAID 控制器的 I/O 处理能力： 133 MB/s 除以 40 MB/s，得到
结果：一个 PCI 总线大约可以连接 3 个 RAID 控制器。大多数的大服务器带有一条
以上的 PCI 总线，这将增加可以安装在单个服务器上的 RAID 控制器的数目。

这些计算表明包括磁盘 I/O 子系统（硬盘驱动器、RAID 控制器、PCI 总线）的组件

传输速率的关系。这些计算假设所有的数据或者全部是顺序存取，或者全部是非顺
序存取，而这在实际数据库服务器环境中是不可能的。现实中，顺序的、非顺序的
存取并存，8­KB 和 64­KB 字节的 I/O 操作同时发生。还有其它一些因素影响可以
同时在一组硬盘上执行的 I/O 操作的数目。主板上的读写缓存使 RAID 控制器增加
了一套硬盘，可以有效提供的 I/O 操作数目。具体的数目难以估计，因为难以估计
SQL Server 环境需要的确切的 8­KB 字节 和 64­KB 字节 I/O 数目。

RAID
当数据库的容量大于几兆字节时，就很有必要对 RAID （廉价磁盘冗余阵列）技术、
以及它与数据库性能的关系做一个基本的了解。

以下是使用 RAID 的一些好处：

12
• 高性能

硬件 RAID 控制器将 Windows 和诸如 Microsoft SQL Server 这样的应用程序中所

有数据的读/写分成若干块（一般情况下大小是 16 KB ­ 128 KB ），这些块分布
在 RAID 磁盘阵列的所有磁盘上。将数据分成小块分布在不同物理磁盘上，这种
做法使 RAID 磁盘阵列中硬盘的 I/O 读写操作比较均匀。这样做提高了磁盘 I/O
的性能，因为 RAID 磁盘阵列中的所有硬盘保持同样的忙程度，而不象在某些不
均匀 I/O 请求情况下，容易造成某些磁盘瓶颈现象的发生。

• 容错性

RAID 提供了对硬盘提供错误保护和数据恢复，使用两种方法：镜像和奇偶校验。

镜像是通过向两个驱动器写信息，一个作为另一个的镜像来实现的。如果镜像
驱动器中的其中一个驱动器中的数据丢失，丢失的数据可以从相应匹配的驱动
器中得到。在 Windows 和 SQL Server 不脱机状态下（称为具有“热插拔（Hot 
Plug） ”）功能的驱动器），大多数 RAID 控制器可以替换一个发生错误的驱
动器，从相应的镜像驱动器中为其恢复数据。当要求具有容错性时，镜像是
RAID 最佳的解决方案。镜像情况下，每个 SQL Server 写操作实际上都要 进行
两次写操作，分别写到镜像对的两边。镜像提供的容错性超过 RAID 的奇偶检验
的容错性。镜像功能可以使服务器在一个磁盘发生错误的情况下仍能继续工作，
并且镜像磁盘中若有一半的磁盘发生错误，它仍可以使系统管理员在不关掉服
务器的情况下，从文件备份中恢复发生错误的磁盘。镜像的缺点是开销过大。
镜像对磁盘的开销要求是：要求两组磁盘都保存有全部数据。RAID 1 和它的衍
生体 RAID 0+1，都是通过镜像功能实现的。

奇偶校验是通过计算写在磁盘上的恢复信息来实现的，这个恢复信息保留在组成磁
盘阵列的一个专门磁盘上，与该磁盘阵列中其它磁盘上的信息共同满足奇偶校验。
如果一个磁盘发生了错误，则在 RAID 磁盘阵列中换入一个新盘，用恢复信息（满
足奇偶校验）将坏盘的内容恢复到新盘上。RAID 5 和它的衍生体都是通过奇偶校
验来实现的。奇偶校验的优点是开销较低。使用 RAID 5，只需要一个额外的磁盘
就可以保护任意数目的磁盘。校验信息均匀分布于组成 RAID 5 的所有磁盘上。奇
偶校验的缺点是性能不高以及容错性不高。因为做校验需要额外的计算开销和写开
销，RAID 5 对每个 Windows NT 和 SQL Server 的写操作都要求四次磁盘 I/O 操作，
而镜像则只需要两次。I/O 读操作的开销与镜像相同。同样的，RAID 5 也仅能在一
个磁盘发生错误的情况下维持工作，而从备份磁盘中恢复数据的工作则需要脱机进
行。

通常的规则是将数据分块使其分布在尽量多的磁盘上，以获取稳定的磁盘 I/O 性能。

性能监控器将显示在特定的 RAID 磁盘阵列中是否有磁盘 I/O 瓶颈。请作好添加磁
盘以及为 RAID 磁盘阵列和/或 SCSI 通道重新分配数据的准备，以备平衡磁盘 I/O
及达到最佳性能之用。

硬件 RAID 控制器自带高速缓存的影响
许多硬件 RAID 控制器有多种读与/或写高速缓存方式。充分利用这种高速缓存能
力，可以提高磁盘子系统的有效 I/O 处理能力 。这些基于控制器的缓存机制的原
理是集合较小的、非顺序的 I/O 请求，这样传到硬盘的批量 I/O 请求可以组成较大
的（32 ­ 128 KB）、而且有可能是顺序的 I/O 请求。这样有助于：在硬盘到 RAID
控制器的 I/O 数目一定的情况下，可以达到更大的数据流量。RAID 控制器缓存正
是极好地利用了硬盘的 I/O 处理能力，来安排 I/O 请求的。

RAID 控制器通常依靠它们的备份功能来保护它们的缓存机制。备份功能指的是在
电源掉电的情况下，可以在一段时间内将写在高速缓存中的数据保存下来。在实际

13
 工作环境中，如果服务器掉电，备份功能将向服务器提供足够的 UPS 保护，从而
提供给数据库服务器更多的保护，将数据库服务器上的数据存到磁盘上。

RAID 级别
在所有的 RAID 级别中，RAID 1 和 RAID 0+1 提供最佳数据保护和最佳性能，但
是它要求较多的磁盘开销。当不需要过多地考虑硬盘价格问题时， RAID 1 或
RAID 0+1 是同时满足高效性和高容错性的最佳选择。

RAID 5 在花费最小的情况下提供了容错功能，但是它的磁盘写效率只有 RAID 1 和
RAID 0+1 的一半，因为 RAID 5 在处理校验信息时，需要额外的磁盘写操作。
RAID 5 的容错性不及 RAID 1 和 RAID 0+1。

使用 RAID 0 (没有容错性保护的磁盘划分)可以获得最佳效率。但是因为它没有容
错性保护，这种 级别的 RAID 只用在数据库开发环境或者某些测试环境中。

当拥有多个物理硬盘驱动器时，许多 RAID 磁盘阵列控制器都提供 RAID 0+1 (也

写做 RAID 1/0 或者 RAID 10) 选项。RAID 0+1 是一种衍生出来的 RAID 方案。它
的低级形式是象普通 RAID 1 一样镜像所有的数据；高级形式则是控制器将数据分
块分布在所有的驱动器上（象 RAID 0）。这样， RAID 0+1 在实现高效性（数据
分块）的同时，又提供了最大限度的保护（镜像）。这些镜像和分块操作对
Windows NT 和 SQL Server 来说是透明的，因为它们都是通过 RAID 控制器来管理
的。RAID 1 与 RAID 0+1 的不同点在于它们的硬件控制器级别不同。RAID 1 和
RAID 0+1 对相同数量的存储要求相同数目的磁盘。若想获得关于具体 RAID 控制
器的 RAID 0+1 的实现细节，请与生产这种控制器的硬件供货商联系。

下面这个图显示了 RAID 0, RAID 1, RAID 5 与 RAID 0+1 的不同点。要保存四个磁

盘的数据， RAID 1 ( 同样也适用于 RAID 0+1)需要八个磁盘进行存储。一定要与
合适的硬件供货商联系，以获取更多的有关运行数据库服务器时 RAID 在硬件上的
实现细节。

普通 RAID 等级

14
联机 RAID 扩充
联机 RAID 扩充是 RAID 的一个特征，它指的是只要有空闲的热插拔插槽，就可以
在不退出 SQL Server 的情况下，动态地向 RAID 磁盘阵列中添加磁盘。许多硬件供
货商都为它们的 RAID 控制器在硬件上实现这一功能。数据将自动在所有磁盘上重
新均匀分块，其中包括新加入的磁盘，而且不需要关掉 SQL Server 或者
Windows。只要在磁盘阵列 容器中留出空闲插槽就可以使用这一功能。这样，如
果 SQL Server 向 RAID 磁盘阵列提出的 I/O 请求总是超过标准（可以通过观察与
RAID 磁盘阵列相联系的 Windows 逻辑驱动器的磁盘队列长度得到），那么可以在
不影响 SQL Server 运行的情况下，向热插拔插槽中加入一个或多个硬盘。RAID 控
制器向这些新插入的磁盘重新分配某些 SQL 数据，以使 SQL 数据均匀分布于
RAID 磁盘阵列的所有磁盘上。这样，RAID 磁盘阵列的总体 I/O 处理能力增强了，
包含进了新磁盘的 I/O 处理能力（每个磁盘每秒 75 次非顺序 I/O 操作，或者 150 次
顺序 I/O 操作）

性能监控器和 RAID
在性能监控器（Performance Monitor）中，逻辑磁盘对象和物理磁盘对象提供相同
信息。不同点是：性能监控器中的逻辑磁盘与 Windows NT 中的逻辑磁盘的相对应；
性能监控器中的物理磁盘与 Windows NT 中的单个物理磁盘相对应。

在命令行窗口使用 diskperf.exe 命令，可以实现性能监控器的计数功能。如果加一
个开关项： diskperf –y ，那么当只使用硬盘、或者 RAID 控制器与硬盘同时使用
时，性能监控器可以报告逻辑盘数目和物理盘数目，而不需使用 Windows NT 的软
件 RAID 方法。

当运行 Windows NT 软件 RAID 时，使用命令：diskperf –ye ，这样性能监控器可

以正确地报告由 Windows NT 分块的物理盘片数目。在这种用 Windows NT 软件方
法分块的情况下，用命令 diskperf –ye，逻辑盘计数器将不能报告正确的信息，它
提供的消息必须舍去。如果用 Windows NT 软件方法分块，而同时又想知道逻辑盘
的数目，那么用 diskperf –y 命令。用 Windows NT 软件方法分块和 diskperf ­y ，逻
辑盘计数器可以报告准确的信息，但是这时物理盘计数器却不能报告准确信息，需
将它提供的消息舍去。

Windows NT 必须重新启动， diskperf ­y 命令才能有效。

硬件 RAID 控制器 将组成 Windows 操作系统的一个 RAID 镜像组（mirrorset）或

磁盘分块（stripeset ）的多个硬磁盘作为一个单独的物理磁盘来处理。磁盘管理器
用来将逻辑盘符与单个的物理磁盘相联系，它不需要知道 RAID 控制器操纵的实际
硬盘数目。

你应该知道 RAID 磁盘阵列中的实际硬盘数目，以便决定 Windows 操作系统 和

SQL Server 向每个物理磁盘发送的磁盘 I/O 请求。将性能监控器报告的、与硬盘相
关的磁盘 I/O 请求数目除以 RAID 阵列中实际的物理硬盘数。

若想估计 RAID 磁盘阵列中每个硬盘的 I/O 活动，请将性能监控器报告的磁盘 I/O

写操作数乘以 2（RAID 1 及 RAID 0+1）,或乘以 4（RAID 5）。这样将准确地计算
出送往物理硬盘的 I/O 请求数。这是物理级的硬盘 I/O 处理能力（每个磁盘 75 次非
顺序操作或 150 次顺序操作）。但是如果当 RAID 使用高速缓存时，不能再用这种
方法计算硬盘的访问次数，因为高速缓存会改变硬盘的实际访问次数。

15
 若不考虑 I/O 产生的问题，监测磁盘排队是一个最佳方案。Windows 操作系统不知
道 RAID 磁盘阵列中的物理磁盘数，因此，为准确评估每个物理磁盘的磁盘排队情
况，需要将磁盘队列的长度除以 RAID 磁盘阵列中包含的物理磁盘数。将这一数据
保存在包含有 SQL Server 文件的两个硬盘中。

若想获取有关 SQL Server 和 RAID 更多的资料，请查看 SQL Server 7.0 联机帮助中

的以下主题：RAID 级别和 SQL Server, 比较不同等级 RAID 的不同实现，监测磁盘
活动，性能管理举例：识别瓶颈现象，关于基于硬件的解决方案，以及 RAID。

Windows NT 软件方式 RAID
Windows NT 通过 Windows NT 操作系统，而不是硬件 RAID 控制器，实现镜像组
（mirrorset）和磁盘分块（stripeset），从而为硬盘提供了容错功能。Windows NT 
磁盘管理器既可以定义镜像组（RAID 1），又可以定义使用奇偶校验的磁盘分块
（RAID 5）。Windows NT 磁盘管理器还允许定义没有容错功能的磁盘分块 (RAID 
0)。

软件方式 RAID 使用更多的 CPU 资源，因为是通过 Windows NT 来管理 RAID，而

不是用硬件 RAID 控制器完成相应的工作。这样，如果处理器接近 100%的利用率，
那么对于同样数目的磁盘，使用 Windows NT 软件方式 RAID 的性能要比使用硬件
RAID 的性能低几个百分点。但是 Windows NT 软件方式 RAID 通常情况下可以使
SQL Server I/O 更好地协同工作，减少了 I/O 瓶颈现象的发生，通过 SQL Server 提
高了 CPU 利用率，增大了数据流量。

若想获取更多的有关配置 Windows NT 软件方式 RAID 的资料，请参考 Windows 

NT Server 联机帮助。也可参考 SQL Server 7.0 联机帮助中的以下主题：关于基于
Windows NT 的磁盘镜像和镜像双方的相互恢复（Duplexing） ，以及关于基于
Windows NT 的磁盘分块和对磁盘分块的奇偶校验。

并行磁 盘 I/O 
对存储在少数硬盘上的较小 SQL Server 数据库来说，磁盘 I/O 并行机制对性能没有
什么影响。但对存储在多数硬盘上的大数据库来说，磁盘 I/O 并行机制使得磁盘子
系统的 I/O 处理能力得以充分利用，大大提高了性能。

Microsoft SQL Server 7.0 引入了文件与文件组的概念，以此来代替 SQL Server 早期
版本的设备模型和段模型。文件和文件组为经过磁盘或 RAID 磁盘阵列的数据传输
提供了更加便利的方法。若想获取更多资料，请参考 SQL Server 7.0 联机帮助中的
以下主题：为文件组加索引，为文件组、文件与文件组建表，使用文件和文件组管
理变化的数据库。

创建单个“磁盘驱动器池”是创建磁盘 I/O 机制的一种技术，该“磁盘驱动器池”

为所有 SQL Server 数据库文件服务，其中不包括传输日志文件。该驱动器池可以是
Windows NT 中作为单个物理磁盘驱动器的单个 RAID 磁盘阵列。较大的驱动器池
也可以由多个 RAID 磁盘阵列和 SQL Server 文件/文件组组成。然后数据库可以在
文件组的基础上创建，这样数据可以均匀地分布在所有的磁盘和 RAID 控制器上。
磁盘驱动器池技术依靠 RAID 对所有物理磁盘上的数据进行分离，以保证在数据库
服务器操作中对数据的并行存取。

16
磁盘驱动器池技术简化了 SQL Server I/O 的性能转化，因为数据库管理员知道只在
一个物理位置创建数据库对象。观察单个设备池，可以了解磁盘排队情况，如果需
要的话，可以在设备池中加入更多的硬盘设备来减少磁盘排队现象的发生。这一技
术可以在不清楚数据库哪一部分利用率最高的情况下达到优化效果。不要隔离其它
磁盘分区提供的 I/O 处理能力，因为 SQL Server 可能有 5%的时间是用它们来做 I/O
操作的。单个磁盘驱动器池技术可以为所有 SQL Server 操作提供合适的 I/O 处理能
力。

SQL Server 日志文件通常应该与所有其它的 SQL Server 数据库文件分开，写到另一

个不同的物理磁盘中。对繁忙使用数据库的 SQL Server，事务日志文件应该在物理
上彼此分开。记录事务日志基本上是顺序化写 I/O 操作。从其它非顺序化磁盘 I/O
活动中分离事务日志处理活动，这样做可以提高 I/O 性能。因为它使包含日志文件
的硬盘集中进行顺序化 I/O 的操作。有时，读事务日志将被作为 SQL Server 操作的
一部分，比如复制、rollbacks 、以及延期修改。参与复制操作的 SQL Servers 管理
程序应当保证所有的事务日志文件有足够的磁盘 I/O 处理能力，因为有时要向它读
数据。

通过 SQL Server 文件和文件组，将 SQL Server 对象从其余的相关数据库中分离出

来，这一工作需要额外的管理。分离对象工作对于研究动态表和动态索引是很有价
值的。通过从所有其它数据库对象中分离表和索引，可以准确地估计 I/O 对象的要
求。当所有的数据库对象被放置在一个磁盘驱动器池中的时候，这个工作并不容易。
当做数据库开发以及数据库基准（benchmarking）时，比较合适进行 I/O 在物理上
的分割，这样就可以把数据库 I/O 信息集合起来，应用在产生数据库产品的计划
中。.

SQL Server 活动可以通过不同的硬盘驱动器、RAID 控制器、PCI 通道、以及它们

的组合，在以下环境下进行分割：

• 事务日志文件

• 临时数据库（ tempdb）

• 数据库文件

• 与查询动作和写动作联系的表

• 与大量查询动作和写动作相联系的非簇索引

使用硬件 RAID 控制器、RAID 热插拔驱动器、联机 RAID 扩展，可以方便地对

SQL Server I/O 动作进行物理上的分割。最灵活的方法是使用 RAID 控制器，这样
可以为每个数据库操作的动作提供一个分离的 RAID SCSI 通道。每个 RAID SCSI
通道都应该与一个分离的热插拔插槽相连，以充分利用联机 RAID 扩展功能（如果
RAID 控制器提供这一功能）。Windows 逻辑盘符与每个 RAID 磁盘阵列相联系，
SQL Server 文件可以在基于已知 I/O 使用模式的不同 RAID 磁盘阵列中进行分离。

在加载测试或者加载大量任务期间，当性能监控器报告发生排队现象时，使用这一
配置可以将磁盘排队与不同的 RAID SCSI 通道以及磁盘驱动器仓联系起来。如果
RAID 控制器和磁盘驱动器仓支持联机 RAID 扩展， 并且磁盘驱动器仓中有空闲热
插拔插槽，可以通过向 RAID 磁盘阵列中添加一定数目硬磁盘的办法解决磁盘排队
问题，具体数目根据性能监控器的报告而定，应使报告中磁盘队列中的磁盘数降到
可以接受的水平（对 SQL Server 来说应少于 2）。这一工作可以在不影响 SQL 
Server 运行的情况下进行。

17
 tempdb 数据库由 SQL Server 创建，是各种操作的共享工作区，包括临时表操作、
用 GROUP BY 或 ORDER BY 命令做排序、子查询、集合操作、用 DISTINCT（必
须创建临时表以删除多余行）命令查询、指针操作、哈希表操作。应当使 tempdb 
数据库的 I/O 操作可以与同事务处理有关的 I/O 操作并行处理。因为 tempdb 是一
个临时工作区，可以不断修改，选择 RAID 1 或 RAID 0+1 比选择 RAID 5 更为合适。
每次数据库服务器重新启动都要重新创建新的 tempdb 数据库，因此对 tempdb 来
说，可以在开发阶段为 tempdb 使用 RAID 0 方式。RAID 0 为 tempdb 数据库使用
最少的物理磁盘，因而提供了最佳的 RAID 性能。在开发环境中为 tempdb 使用
RAID 0 需要考虑以下事实：在 RAID 0 方式下，当物理磁盘发生错误时，SQL 
Server 必须停止运行，重新启动，而在 RAID 1 或 RAID 0+1 方式下则不用。

要移动 tempdb  数据库，使用 ALTER DATABASE 命令来改变与 SQL Server 

tempdb  数据库关联的逻辑文件名所代表的物理文件位置。例如， 移动 tempdb 数
据库文件和它相关联的日志文件到新的位置 E:\Mssql7 和 C:\Temp, 可以使用下面的
命令：
alter database tempdb modify file (name='tempdev',filename= 'e:\mssql7\tempnew_location.mDF')
alter database tempdb modify file (name='templog',filename= 'c:\temp\tempnew_loglocation.LDF')
开发工作中，与用户数据库相比较而言，不经常使用 master、 msdb 和 model 数
据库，因此它们在 I/O 性能转换过程中没有加以过多的考虑。master 数据库仅仅用
来添加新的注册登记、添加数据库，以及添加其它系统对象之用。

B 树结构中含有非簇索引，B 树 结构可以用 ALTER DATABASE 命令来分离相关

的数据库表。在这个例子当中，第一个 ALTER DATABASE 创建了一个文件组。第
二个 ALTER DATABASE 创建了一个与文件组相联系的、使用分离物理定位的文件。
在这一点上，可以根据文件组建立索引，此索引称之为 index1。存有过程报告文件
和文件组的 sp_helpfile 提交一个指定的数据库。sp_help tablename 在输出部分提
供了表索引信息和文件组关系信息。
alter database testdb add filegroup testgroup1
若想获
alter database testdb add file (name = 'testfile',
取更多
filename = 'e:\mssql7\test1.ndf') to filegroup testgroup1
资料，
create table test1(col1 char(8)) 请参考
create index index1 on test1(col1) on testgroup1 SQL 
Server 
sp_helpfile 7.0 联
sp_help test1 机帮助
中的以下主题及/或关键字： ALTER DATABASE, sp_helpfile, 文件与文件组（Files 
and Filegroups）, 为文件组加索引，管理磁盘活动，物理数据库文件和文件组，添
加数据与删除数据，事务日志文件。

这部分讲述的是 SQL Server 数据和索引在磁盘上是如何
物理放置的、以及这样的结构是如何影响磁盘 I/O 的性
SQL Server 索引 能的。

SQL Server 数据页和索引页的大小都是 8 KB 字节。 SQL Server 数据页包含了所有

与表中的列相关的数据，除去 text 和 image 的数据。SQL Server 数据页包含与 text 
或 image 列相关的行，在处理 text 和 image 数据时，使用一个指向表示一个或多
个 8­KB 页面的 B 树指针。

18
SQL Server 索引页只包含来自列的数据，列由一个特殊的索引组成，因此索引页可
以将许多行的信息压缩到一个 8­KB 的页面中，而不是象数据页那样 8­KB 的页面
只能表示 8­KB 的数据。索引对 I/O 性能的提高正是通过这种形式的压缩实现的。
如果作为索引的列在数据表中只占有很少的百分比，那么在 8­KB 大小 的索引页中
可以压缩更多的信息，这样更提高了性能。当 SQL 查询要求表中的若干行内容，
使索引页的列与数据页的行匹配，那么 SQL Server 可以读索引页来减少 I/O 操作，
然后直接存取满足查询要求的数据页的相应行。这样 SQL Server 在定位要求的行时，
不需要扫描数据表中所有的行 。

SQL Server 索引基于由 8­KB 索引页组成的 B 树 结构。簇和非簇索引的区别在于 B

树结构的底部（也称为叶节点层­leaf level）。 索引 B 树 结构的顶部称为非叶节点
层­nonleaf leve。B 树 结构包含了所有定义在 SQL Server 表中的单个索引。

下图显示了非簇索引与簇索引的不同点。在非簇索引中，叶节点只包含索引数据。
在非簇索引的叶节点上，索引行包含有指向行数据的指针，该行数据在相应数据页
上。非簇索引在最坏情况下，对每一行的存取都要求额外的非顺序磁盘 I/O 来检索
该行数据；在最好情况下，许多要求检索的行数据都在相同的数据页上，这样检索
若干行只需访问一次页面。簇索引中，索引的叶节点是实际的数据行。这样，在检
索数据表时，不需要做特殊的查找标志。基于簇索引的确定范围扫描有很好的执行
性能，因为簇索引（也就是表中所有行）的叶节点在物理磁盘上是按列顺序排列的，
这些列组成了一个簇索引，可以执行 64­KB 以内的 I/O。如果在簇索引 B 树内（非
叶节点层和叶节点层）页面数不多，不会造成页面分割，那么 这些 64­KB 的 I/O
在物理上便是顺序存放的。加点的行表示 B 树 结构中没有在图中表示出来的其它
8­KB 页面。

簇索 引
每个表只能够有一个簇索引，因为当象非簇索引 B 树结构那样组织簇索引 B 树结构
的顶部时，簇索引 B 树的底层将包含与表有关的实际 8-KB 数据页。以下是性能含
义：

19
 • 利用簇索引、基于键值搜索的 SQL 数据检索无需利用书签查找 (和可能的硬盘
位置无序变动)就可以检索相关数据页，因为簇索引的叶层次已经是相关数据页。
• 簇索引的叶层次按照包括该簇索引的列进行排序。由于簇索引 的叶层次包含表
的实际 8-KB 数据页，因此整个表的行数据就按照簇索引所确定的顺序被物理地
安排在磁盘驱动器上。根据簇索引的值从大于 64-KB 的表中取出相当多的行时，
这将提供一个潜在的 I/O 性能优势，因为除非正在对表进行分页，正在使用的
都是顺序磁盘 I/O。有关分页的进一步信息，请参见本文档后面部分的
“FILLFACTOR and PAD_INDEX”。你在表中挑选簇索引时，应该基于某一列，
该列用于执行域扫描以获取数量较多的行。

非簇 索引
对于要从一个大的 SQL Server 表中，根据一个键值取出具有较好选择性的一些行的
情况来说，非簇索引是最有用的。非簇索引是 B 树形式的 8­KB 索引页。索引页 B
树的底层或叶层次包含所有来自包含该索引列的数据。当使用一个非簇索引来检索
与键值相匹配的表的信息时，遍历索引 B 树，直到在索引的叶层次找到匹配键。如
果需要来自表中的列（该列不构成索引的一部分）时，则将进行书签查找。书签查
找可能会需要一个磁盘的无序 I/O 操作。如果表及其附带的索引 B 树很大，就可能
还需要从另一个磁盘中读取数据。如果多个书签查找都链接到相同的 8­KB 数据页
上，那么能够减少 I/O 性能损失，因为只需一次性地将该页读取到数据高速缓存中。
对于 SQL 查询所返回的每一行（该查询与查找非簇索引有关），都需要一个书签
查找。对于只从表中返回一行或少数行的 SQL 查询而言，这些书签查找使得能够
更好地对非簇索引进行归类。对于需要返回许多行的查询而言，簇索引更有用处。

有关进一步的信息，请参见 SQL Server 7.0 联机手册中的关键字： 非簇索引

（Unclustered Index）。

覆盖 索引
覆盖索引是非簇索引的一种特殊情况。覆盖索引就是一个非簇索引，但是它建立在
满足 SQL 查询所需的所有列上，查询可以在选择标准中，也可以在 WHERE 子句
中。覆盖索引可以节约 I/O，并且能够提高查询性能。但是你应该在创建一个新索
引所花费的代价（包括对与其相关的 B 树索引结构进行维护所需要的代价)和覆盖
索引所能带来的 I/O 性能收益之间进行权衡。如果对于经常在 SQL Server 上运行的
一个查询或一组查询来说，覆盖索引是有用的，那么创建覆盖索引就很值得。

示例：
SELECT col1,col3 FROM table1 WHERE col2 = 'value'
CREATE INDEX indexname1 ON table1(col2,col1,col3)
或者

在 SQL Server Enterprise Manager 中，使用 Create Index Wizard。

本示例中的 indexname1 索引是一个覆盖索引，因为它包括 SELECT 语句和

WHERE 子句中的所有列 。在查询的执行过程中，SQL Server 不需要存取与 table1
有关的数据页。利用名为 indexname1 的索引，SQL Server 可以包含查询所需的所
有信息。当 SQL Server 已经遍历了与 indexname1 有关的 B 树并找到 col2 等于其值
之处的索引键域时，SQL Server 将从覆盖索引的叶层次取出所有需要的数据
(col1,col2,col3)。这样就以两种方式展现了 I/O 性能：

20
• SQL Server 从索引页而不是数据页得到所需要的数据，从而数据压缩比例更大，
而且 SQL Server 将节约磁盘的 I/O 操作。

• 利用 col2， 覆盖索引将需要的数据组织到磁盘上。硬盘驱动器按照顺序返回与
WHERE 子句(col2 = 值)有关的所有索引行，这样就能实现更好的 I/O 性能。从
磁盘 I/O 的角度来看，一个覆盖索引就是此查询和其它查询的一个簇索引，它完
全能由覆盖索引中的列实现。

如果索引中所有列的字节数比该表中单行的字节数小，而你又能确信利用覆盖索引
进行的查询将会很顺畅，那么使用覆盖索引就是很明智的。但是，在构建大量的覆
盖索引之前，需要考虑 SQL Server 7.0 如何才能有效地、自动地迅速为查询创建覆
盖索引。

自动 的覆 盖索 引或覆 盖查 询
Microsoft SQL Server 7.0 Query Processor 提供了索引交集。索引交集允许查询处理
器兼顾到给定表中的多个索引，构建一个基于这些多个索引的散列表，利用散列表
来缩减查询的 I/O。索引交集生成的散列表就是一个覆盖索引，它能提供与其它覆
盖索引一样的 I/O 性能。索引交集给数据库用户环境提供了更大的灵活性，在该环
境中要确定所有运行于此数据库之上的查询是很困难的。在这种情况下，一个较好
的策略是定义单一的列，并且定义关于所有经常要被查询的列的非簇索引，让索引
交集来处理需要覆盖索引的情况。

有关进一步的信息，请参见 SQL Server 7.0 联机手册中的下列主题： 查询调整建议

（Query Tuning Recommendations）和设计索引（Designing an Index）。

示例：
SELECT col3 FROM table1 WHERE col2 = 'value' 或者
CREATE INDEX indexname1 ON table1(col2)
CREATE INDEX indexname2 ON table1(col3)
在 SQL 
Server Enterprise Manager 中，使用 Create Index Wizard。

在此示例中，indexname1 和 indexname2 是非簇索引，是创建在名为 table1 的

SQL Server 表之上的单个列。执行查询时，查询处理器识别出使用两个索引的索引
交集是有用的。查询优化器自动地同时杂凑两个索引，从而在执行查询时节省
I/O。无需查询线索。覆盖索引所处理的查询 (无论是利用显式声明的覆盖索引还
是索引交集)一律称为覆盖查询。

索引 选择
选择索引的方式会极大地影响产生的磁盘 I/O 次数，从而影响到 I/O 性能。非簇索
引对于少数行的检索是合适的，而簇索引则适合于域扫描。另外，你应该使索引尽
量简洁（使用最少的列和字节），对于簇索引尤其如此，因为非簇索引是利用簇索
引来查找行数据的。有关进一步的信息，请参见 SQL Server 7.0 联机手册中的下列
主题：使用簇索引（Using Clustered Indexes），索引调整建议（Index Tuning 
Recommendations）和设计索引（Designing an Index）。

必须考虑到非簇索引的选择性，因为如果非簇索引是利用少数单一值的，并且创建
于一个较大的表之上，那么在检索数据的过程中使用非簇索引就不能节约 I/O 了。
实际上，使用索引将导致比顺序表扫描更多的 I/O。非簇索引可能的选择项包括发
票号码，单一顾客号，社会安全号和电话号码。

21
 对于匹配列的查询、或者搜索单一值很少的列域查询而言，簇索引比 非簇索引要
好得多，因为簇索引本身对表的数据进行了排序，而且允许关于键值的 64­KB 的
I/O。簇索引可能的选择项包括国家，公司分支机构，销售日期，邮政编码和顾客
所在地。定义关于具有单一值的列的簇索引是不明智的，除非系统的典型查询能检
索到较大范围内的单一值。选取每个表中最好的列来创建簇索引，这一行为取决于
是否具有多个查询，这些查询必须能取出基于这些列的顺序的很多行。对于每个用
户环境而言，答案是很明显的。一个公司可能做更多的基于数据域的查询，而另一
个公司可能会做许多关于分支银行域的查询。

以下是 WHERE 子句的一些示例，这些示例可以通过簇索引得到优化：

…WHERE <column_name> > some_value
…WHERE <column_name> BETWEEN some_value AND some_value
…WHERE <column_name> < some_value

簇索 引选 择
簇索引选择实际上包括两个步骤。首先，向域扫描提供顺序 I/O，以便确定表中那
些能够从簇索引得到好处的列。接着，利用簇索引来影响表中数据的物理位置安排，
此时要避免热点（hot spot）。热点的产生是由于当数据放置于硬盘之上时，有若
干个查询同时想在数据所在硬盘的同一个区域内对该数据进行读取和写入操作。这
就导致了磁盘瓶颈，因为硬盘收到了超过它所能处理的多个并发磁盘 I/O 请求。解
决方法是要么停止从此磁盘检索那么多的数据，要么将数据散布到多个磁盘上以满
足 I/O 要求。对于在成百上千个 SQL Server 用户之间更好地进行数据的并发存取而
言，有关数据物理位置安排的考虑是很关键的。

这两个解决方案往往是互相冲突的，故而最好的解决方案是协调均衡好两者的关系。
在高用户负载的环境下，与通过在列上加入簇索引以改善性能相比，通过热点来提
高并发性要更有价值。

对于 SQL Server 7.0，在表中有簇索引的情况下，非簇索引将使用簇索引来查找数
据行。由于所有的非簇索引，都需要在其 B 树结构中保持簇键，所以最小化键的字
节大小能够改善性能。请保持簇索引中列的数量最小，并认真考虑包括在簇索引中
的每一列的字节大小，这将有助于缩减簇索引的大小，从而缩减表中所有非簇索引
的大小。越小的 B 树结构可以读得越快，这有利于提高性能。有关进一步的信息，
请参见 SQL Server 7.0 联机手册中的下列主题：使用簇索引（Using Clustered 
Indexes）。

在 SQL Server 的早期版本中，向没有簇索引的表 (称为堆 heap ) 中插入的行被置于

磁盘中表的末尾。这将导致在一个很忙的表的末尾出现热点的可能。SQL Server 
7.0 存储管理算法提供的自由空间管理能够避免这种现象。向堆中插入行时，SQL 
Server 使用 Page Free Space (PFS) 页在表中快速查找可用的自由空间，以便插入这
些行。PFS 页搜索整个表找到自由空间，恢复被删除的空间并避免插入热点。自由
空间管理会影响到簇索引。由于簇索引影响数据的物理位置安排，因而当簇索引本
身基于某一列进行排序，在执行超过最大列值的多个并发插入操作，而且这些插入
都针对同一个磁盘物理位置时，可能会形成热点。对于单调递增值的列而言，簇索
引顺序地按照该列来组织磁盘上的数据行。通过将簇索引置于另一列上，或者通过
不在该表中包括簇索引，此顺序数据安排将移到另一列或者根本就不发生。

另一个方法是从热点位于选择的上下文之中这一思想入手。如果许多用户利用非常
接近但却并不在同一行的键值来选择数据，那么大部分磁盘 I/O 将在磁盘 I/O 子系
统的物理区域内发生。通过为该表将簇索引定义到某一列中（该列可在磁盘上更均
匀地散布这些键值），这一磁盘 I/O 行为可以更均匀地散布开来。如果所有选择使
用的都是同一个单一键值，那么使用簇索引将不能均衡此表的磁盘 I/O。通过使用
RAID (既可以是硬盘也可以是软盘)将 I/O 散布到多个磁盘驱动器上，你可以缓解这
一问题。这一行为可以归结为磁盘存取问题，而不是封锁问题。

22
簇索 引选 择方 案
一个方案可以阐明簇索引选择。例如，一个表中包含有一个发票日期列，一个单一
发票号码列和其它数据。每天大约有 10,000 个新记录要插入到这个表中， SQL 查
询经常要搜寻这个表的所有记录以得到一个星期以来的数据。有许多用户对此表进
行并发存取。发票号码不是簇索引的选择项。发票号码是单一的，用户并不经常搜
寻发票号码域，因此在磁盘上顺序存放发票号码是不合适的。同时，发票号码值单
调递增 (1001，1002，1003，依次递加)。如果簇索引按发票号码设置，则在同一个
磁盘物理位置，在表的末尾、最大发票号码之旁，将会发生多个新行的插入，这将
导致一个热点。

考虑发票日期列。最大化顺序 I/O 需要将发票日期列作为簇索引的侯选项，因为用

户经常搜寻一个星期的数据(大约 70,000 行)。但是从并发的角度来看，发票日期列
可能不是簇索引的侯选项。如果簇索引按发票日期设置，则所有数据都将被插入到
表的末尾，这样硬盘上表的末尾处将发生热点。表末尾处的插入被同一日期插入的
10,000 行抵消，因此发票日期导致热点的可能性比发票号码小。同时，硬件 RAID
控制器有助于在多个磁盘上散布这 10,000 行，这还将最小化发生插入热点的可能
性。

关于此方案没有完美的解答。你可以按发票日期放置簇索引，从而虽然有热点的危
险，但是能够加速与发票日期域有关的查询。 在这种情况下，你可以监控磁盘上
与此表有关的磁盘队列，随时发现可能的热点。推荐你按发票日期定义簇索引，因
为域扫描的优点是基于发票日期的，从而发票号码在磁盘上不是顺序排列的。

在本示例中，一个表包含发票号码，发票日期，发票数量，产生销售的销售部门以
及其它数据。假定每天要插入 10,000 条记录到此表中，而且用户经常根据销售部
门查询发票数量。销售部门应该是创建簇索引的列，因为那是扫描所基于的范围。
最近插入的行将具有销售部门的混合数据；插入应该在表中和表所在的磁盘中均匀
地散布。

在一些情况下，范围扫描可能不成问题。例如，一个大的雇员表有雇员号，社会安
全号和其它数据。插入行时，雇员号依次增加。每天要对此表进行 100,000 次操作，
每次操作就是根据社会安全号取出一行。创建于社会安全号之上的非簇索引在此方
案中提供了非常不错的查询性能。基于社会安全号的簇索引比基于非簇索引所提供
的查询性能要稍微好一点，但是可能有点多余，因为范围扫描并不棘手。如果此表
只有一个索引，则应按社会安全号这一列来放置簇索引。接下来的问题是是否要定
义此表的簇索引。在 SQL Server 的早期版本中，定义表的簇索引是很重要的（即使
查询无需如此），因为这有助于恢复删除了的行的空间。这对于 SQL Server 7.0 空
间分配算法和存储结构而言是不存在任何问题的。

对本示例的建议是创建基于社会安全号的簇索引。理由是社会安全号具有分布式数
据，因而不具有雇员号的顺序模式，社会安全号往往具有较平稳的分布。如果簇索
引创建于此均匀分布的列数据之上，那么雇员记录将均匀地分布在磁盘上。这一分
布，结合 FILLFACTOR 和 PAD_INDEX（这将在今后详加论述），为整个表提供了
开放式数据页来插入数据。假定最近插入的雇员记录具有社会安全号的均匀分布，
则将均匀填写雇员表，避免分页。如果表中不存在具有平稳分布的列，那么在表中
创建整数列并在列中放入均匀分布的值，然后创建簇索引列是很值得的。具有簇索
引的 “filler” 或 “dummy”列不是用来查询的，而是用来在磁盘驱动器间均匀分布
数据 I/O，从而提高表的存取并发性和整体 I/O 性能。这对于大的、存取频繁的
SQL 表而言是一个有效的方法。本示例中另一个可行的解决方案是不创建此表的簇
索引。在这种情况下，SQL Server 7.0 控制着空间管理的各个方面。SQL Server 找
到一个空闲空间以插入行，重用已删除行的空间，并且在需要时自动识别磁盘上数
据页的物理顺序(以允许更大量的 I/O 序列)。数据页的识别在数据库文件自动压缩
的过程中进行。有关进一步的信息，请参见 SQL Server 7.0 联机手册中的下列主题：
管理对象所用的空间和空间分配及重用（Managing Space Used by Objects and Space 
Allocation and Reuse）。

23
 FILLFACTOR 和 PAD_INDEX
如果正在对一个 SQL Server 数据库进行大量的插入操作，那么你就应该提供并维
持索引和数据页的开放空间，以避免分页。当索引页或数据页不能再容纳更多的新
行，或者由于该页中定义的逻辑顺序必须向页中插入一行时，就会导致分页。发生
分页时，SQL Server 必须将数据分到整个页中，并将大约一半的数据移到新页，从
而两页将具有相同的开放空间。这就耗费了系统资源和时间。

最初建立索引时，SQL Server 将索引 B 树结构放入邻近的物理页中，利用 I/O 序列

扫描索引页来支持最优 I/O 性能。发生分页，并且新页必须插入到索引的逻辑 B 树
结构中时，SQL Server 必须在某处分配新的 8­KB 索引页。这发生在硬盘驱动器的
其它地方并打乱了原本有序的索引页。这使得 I/O 操作由有序转换为无序，并使性
能减半。可以通过重建索引来恢复原本有序的索引页来解决分页过多的问题。这一
现象还可能发生在簇索引的叶层次上，影响到表的数据页。

利用性能监控器（Performance Monitor）来监控 SQL Server: Access Methods ­ Page 
Splits 计数器。此计数器的值非零则表示发生了分页。进一步的分析要由 DBCC 
SHOWCONTIG 语句完成。有关如何使用此语句的进一步信息，请参见 SQL Server 
7.0 联机手册中的下列主题： DBCC SHOWCONTIG。

DBCC SHOWCONTIG 语句可以揭示表中是否有过多的分页。扫描密度是 DBCC 
SHOWCONTIG 提供的关键指示器。其值应该尽量接近百分之百。如果此值低于百
分之百，可通过使用 DROP_EXISTING 选项整理表以重建表的簇索引 。CREATE 
INDEX 语句的 DROP_EXISTING 选项允许重新创建已有的索引，并且它提供的索
引重建性能比删除后再重建索引更好。关于进一步信息，请参见 SQL Server 7.0 联
机手册中的下列主题：创建索引和重建索引（ CREATE INDEX and Rebuilding an 
Index）。

CREATE INDEX 和 DBCC DBREINDEX 语句的 FILLFACTOR 选项提供了确定开放

空间百分比以放置索引和数据页的方法。CREATE INDEX 的 PAD_INDEX 选项适
用于在非叶层次索引页上为 FILLFACTOR 确定的要求。没有 PAD_INDEX 选项，
FILLFACTOR 主要影响簇索引的叶层次索引页。对于 FILLFACTOR 你应当使用
PAD_INDEX 选项。关于进一步的信息，请参见 SQL Server 7.0 联机手册中的下列
关键字：分页与 PAD_INDEX（ page split and PAD_INDEX）。

为 FILLFACTOR 确定的最佳值取决于在一个给定的时间范围内有多少新数据插入
到了 8­KB 索引和数据页中。请记住 SQL Server 索引页一般包含比数据页更多的行，
因为索引页只包含与该索引有关的列的数据，而数据页包含有整个行的数据。同时
请考虑维护窗口多久出现一次，此维护窗口允许索引重建以避免分页。当大部分索
引和数据页通过选择表的簇索引填入了数据时，就应该尽量重建索引。如果簇索引
均匀地分布数据，使得可以在整个与表有关的数据页之间插入新行，那么将均匀地
填写数据页。这在分页前提供了时间，你必须重建簇索引。对 FILLFACTOR 的选
择，应部分地基于行（这些行将在一定的时间范围内插入到一个页的键域中）的估
计数目，部分地基于系统中多久会发生一次计划的索引重建。

你必须根据性能平衡，对在页中保留许多开放空间及分页这两者之间做一个抉择。
为 FILLFACTOR 指定一个较小的比例将会给索引和数据页留下较大的开放空间，
这有助于避免分页，但却抵消了将数据压缩到一页中所获得的一些良好性能。如果
在索引和数据页有更多的数据压缩，SQL Server 将会执行得更快一些，因为它能利
用更少的页和 I/O 取出更多的数据。指定过高的 FILLFACTOR 可能会给页面留下过
小的开放空间，还可能使得页面过快溢出，这将导致分页。

24
 在使用 FILLFACTOR 和 PAD_INDEX 之前，请记住即便是在联机事务处理(OLTP)
系统中，读取操作也将会超过写入操作。使用 FILLFACTOR 会减慢所有的读取操
作，因为它将表散布到一个大的区域里（缩减数据压缩）。在使用 FILLFACTOR 
和 PAD_INDEX 之前，你应当使用性能监控器来比较 SQL Server 读取和 SQL Server 
写入，而且只有在写入操作实质上是读取操作的一部分（超过百分之三十）时才能
使用这些选项。

如果写入操作是读取操作的一部分，那么在繁忙的 OLTP 系统中最好的方式是指定

一个 FILLFACTOR，它可以留下每 8­KB 页面的自由空间最小数量，但又仍能避免
分页，允许 SQL Server 到下一个时间窗口重建索引。这一方法兼顾了调整 I/O 性能
（使页面尽可能地满）和避免分页（不出现页面溢出）两个方面。你可以进行实验，
利用不同的 FILLFACTOR 值重建索引，然后模拟表的装载行为以确认
FILLFACTOR 的最优值。在确定了最优 FILLFACTOR 值之后，自动将预定的索引
重建作为一项 SQL Server 任务。关于进一步的信息，请参见 SQL Server 7.0 联机手
册中的下列关键字：创建任务（creating a task）。

微软公司的 SQL Server 第七版包括可以

帮助数据库管理员进行性能调整的几种
SQL Server 性能调整工具 工具。

样本数据和工作负载
这个例子说明了如何使用 SQL Server 的性能工具。首先，创建表格：
CREATE TABLE testtable (nkey1 int IDENTITY, col2 char(300) DEFAULT 'abc', ckey1 char(1))
接下来，在表格中装入 10,000 行测试数据：
DECLARE @counter int 这些查询包含
SET @counter = 1 了以下的数据
WHILE (@counter <= 2000) 库服务器工作
BEGIN 负载：
INSERT testtable (ckey1) VALUES ('a')
SELECT ckey1,col2 FROM testtable WHERE ckey1 = 'a'
INSERT testtable (ckey1) VALUES
select('b')
nkey1,col2 FROM testtable WHERE nkey1 = 5000
INSERT testtable (ckey1) VALUES ('c')
INSERT testtable (ckey1) VALUES ('d')
INSERT testtable (ckey1) VALUES ('e') SQL Server 配置
SET @counter = @counter + 1 文件
END
SQL Server 配
置文件记录详细描述了发生在数据库服务器上的活动的信息。SQL Server 可以进行
配置，以观察和记录一个或者多个用户在 SQL Server 上执行的查询，以及提供更多
的可配置性能信息，这些信息包括 I/O 次数的统计，CPU 的统计，封锁请求，SQL
事务和 RPC 统计，索引和表格浏览，提出警告和错误，创建和删除数据库对象，
连接和删除已建立的连接，存储程序的操作，光标操作，以及更多的信息。有关
SQL Serverprofiler 能记录的进一步信息，请参见 SQL Server 联机手册中的关键字：
SQL Server 配置文件（SQL Server Profiler）。

使用 带有 索引 调整向 导（ Index Tuning Wizard）的 SQL Server 配置文

件
SQL Server 配置文件和索引调整向导能一起用来帮助数据库管理员在表格上创建适
当的索引。SQL Server 配置文件将查询占有的资源记录到一个.trc 文件中。索引调
整向导可读取这个.trc 文件，并且对.trc 文件中的信息和数据库中的表格进行评价，

25
 以及对将要建立的索引提出建议。索引调整向导不仅能通过调整创建的自动索引来
自动创建数据库的索引，而且可以产生一个 SQL 事务脚本，这个事务脚本可以在
以后进行评价和执行。

下面是分析一个查询负载的步骤：

⇒ 建立 SQL Server 配置文 件(企业管 理器 )

1. 在 Tools 菜单上，点击 SQL Server 配置文件。
2. 在 File 菜单上，指向 New，并点击 Trace。
3. 为该跟踪键入一个名字。
4. 选择 Capture to file，接着选择一个.trc 文件，并将 SQL Server 配置文件的信息
输出到该文件中。

⇒ 运行 工作 负载 （企业 管理 器）
1. 在 Tools 菜单上，点击 SQL Server Query Analyzer。
2. 连接 SQL Server，并设置将要创建表格的当前数据库。
3. 将下面的查询写到 SQL Server 查询分析器（SQL Server Query Analyzer）的查
询窗口：
SELECT ckey1,col2 FROM testtable WHERE ckey1 = 'a'
SELECT nkey1,col2 FROM testtable WHERE nkey1 = 5000
1. 在 Query 菜单上，点击 Execute。

⇒ 停止 SQL Server 配置文 件
1. 在 File 菜单上，点击 Stop Trace。
2. 在 Stop Selected Traces 对话框中，选择将要停止的跟踪。

⇒ 将.trc 文件 调入 到索 引调整 向导 中（ SQL Server 配置文 件）

1. 在 Tools 菜单上，点击 Index Tuning wizard 并点击 Next。
2. 选择将要分析的数据库，并点击 Next。
3. 确认 I have a saved workload file 已经选定，并点击 Next。
4. 选择 My workload file，查找由 SQL Server 配置文件创建的.trc 文件。
5. 在 Select Tabled to Tune 中，选择表格并点击 Next。
6. 在 Index Recommendations 中，选择将要创建的索引，并点击 Next。
7. 选择所喜欢的选项，点击 Next。
8. 点击 Finish。

以下由索引调整向导为样本数据库和工作向导所生成的 SQL 事务：

26
/* Created by: Index Tuning Wizard */
/* Date: 9/7/98 */
/* Time: 6:42:00 PM */
/* Server: HENRYLNT2 */
/* Database : test */
/* Workload file : E:\Mssql7\Binn\Profiler_load.sql */

USE [test]
BEGIN TRANSACTION
CREATE CLUSTERED INDEX [testtable2] ON [dbo].[testtable] ([ckey1])
if (@@error <> 0) rollback transaction
CREATE NONCLUSTERED INDEX [testtable1] ON [dbo].[testtable] ([nkey1])
if (@@error <> 0) rollback transaction
COMMIT TRANSACTION
这些索引是由索引调整向导为预期的样本表和数据所产生的。ckey1 仅有五个单独
的值，每个值有 2000 行。因为有一个样本查询（SELECT ckey1,col2 FROM 
testtable WHERE ckey1=a）需要从基于 ckey1 的一个值的表中进行恢复，所以在
ckey1 列建立簇索引是适当的。第二个查询（SELECT nkey1,col2 FROM testtable 
WHEWE nkey1=5000）取得以 nkey1 列的值为基础的一行。nkey1 是唯一的，它有
10,000 行：因此，应该在这一列上建立一个非簇索引。

在含有许多表格和查询的数据库服务器环境中，SQL Server 配置文件和索引调整向
导都是非常强大的工具。当数据库服务器正在进行一个有代表性的查询时，可以用
SQL Server 配置文件记录一个.trc 文件。接着将.trc 文件调入索引调整向导中，以决
定将要建立什么索引比较合适。按照索引调整向导中的提示自动产生和安排索引创
建工作，以使其运行较少的次数。有规律地运行 SQL Server 配置文件和索引调整向
导（如每周一次），能够观察在数据库服务器上执行的查询是否发生了明显的改变，
这样可能需要不同的索引。SQL Server 配置文件和索引调整向导的有规律的使用可
以在查询工作量改变和数据库大小随着过去的时间增加的时候，使 SQL 服务器以
最高的模式运行。

有关进一步的信息，请参见 SQL Server 7.0 联机手册中的下列主题： 索引调整向导

和索引调整建议（Index Tuning Wizard and Index Tuning Recommendations）。

分析 SQL Server 配置 文件 信息
SQL Server 配置文件提供一个将日志信息调入一个 SQL 服务器表格的选项。当选
定时，可以查询表格，以便决定特定的查询中是否用到了过多的资源。

⇒ 将 SQL Server 配 置文件 信息 调入到 一个 SQL Server 的 表格（ 企业 管理器 ）

中

1. 在 Tools 菜单上，点击 SQL Server Profiler。

2. 在 File 菜单上，指向 New ，点击 Trace。
3. 为该跟踪键入一个名字，选择 Capture to Table。
4. 在 Capture to Trace 对话框中，键入一个可以把 SQL Server 配置文件的信息
输出到里面的数据库的表格名称。点击 OK。
5. 在 File 菜单上，点击 Stop Trace。
6. 在停止跟踪（Stop Traces）对话框中，选择将要停止的跟踪。

27
 有关进一步的信息，请参见 SQL Server 7.0 联机手册中的下列主题：视图和跟踪分
析（Viewing and Analyzing Traces），SQL Server 配置文件的故障解决
（Troubleshooting SQL Server Profiler），使用 SQL Server 的技巧（Tips for Using 
SQL Server），一般 SQL Server 配置文件简介（Common SQL Server Profiler 
Scenarios），SQL Server 配置文件的启动（Starting SQL Server Profiler），以及用
SQL Server 配置文件进行监控（Monitoring with SQL Server Profiler）。

SQL Server 查询 分析 器
当信息已经记录到 SQL Server 的表格中后，你可以使用服务器查询分析器来决定在
系统上的哪个查询使用的资源最多，从而数据库管理员可以集中精力来提高那些最
需要提高效率的查询。例如，以下这个查询是典型的分析，该分析是建立在从 SQL 
Server 配置文件记录到一个 SQL Server 表格的数据上的：
select top 3 TextData,CPU,Reads,Writes,Duration from profiler_out_table order by cpu desc
这个查询找出在数据库服务器上使用 CPU 资源最多的三个程序。随之返回在几毫
秒时间内读写 I/O 次数的信息。如果 SQL Server 配置文件记录了大量的信息，那么
你就应该创建这些表格的索引，以加速查询的分析。例如，如果 CPU 是分析这张
表的一个重要标准，有应该在 CPU 这一列创建一个非簇索引。

I/O 次数 统计
SQL Server 查询分析器（SQL Server Query Analyzer）在 Connections Options 对话框
的 General 标签下面提供一个 Show stats I/O 的选项。如果想要了解在刚刚执行的查
询中消耗了多少的 I/O 资源的信息，请在服务器查询分析器上选定这个检查框。

例如，当选定了 Show stats I/O 的连接选项时，查询 SELECT ckey1,col2 FROM 

testtable WHERE ckey1=a 除了返回结果外，还返回该查询 I/O 次数的信息：
Table 'testtable'. Scan count 1, logical reads 400, physical reads 382, read-ahead reads 400.
类似的，当选定 Show stats I/O 的连接选项时，查询 SELECT nkey1,col2 FROM 
testable WHERE nkey1=5000 除了返回结果外，还返回该查询 I/O 次数信息：
Table 'testtable'. Scan count 1, logical reads 400, physical reads 282, read-ahead reads 400.
使用 STATISTICS I/O 是一个监控查询调整效果的好方法。例如，按照索引调整向
导建议的样本数据创建两个索引，接着再运行一次该查询。

在查询 SELECT ckey1,col2 FROM testtable WHERE ckey2=a 中，簇索引提高了下列

程序的性能。这个查询一定得取得表的百分之二十，因此，性能的提高是合情合理
的。
Table 'testtable'. Scan count 1, logical reads 91, physical reads 5, read-ahead reads 32.
在查询 SELECR nkey1,col2 FROM testtable WHERE nkey1=5000 中，非簇索引的创
建对于查询性能有突出的效果。因为 10,000 行的表中仅有一行必须被从表中取出，
因此，有非簇索引的性能提高是合情合理的。
Table 'testtable'. Scan count 1, logical reads 5, physical reads 0, read-ahead reads 0.
ShowPlan
showplan 可以用来显示查询优化器正在做什么的详细信息。SQL Server7.0 提供了
showplan 文本和图形的版本。图形 showplan 的输出可以用 Ctrl+L 来执行一个事务
查询，在 SQL Server 查询分析器的结果的边上显示出来。如果执行了查询，图标将
会指示出查询优化的操作。箭头表示查询的数据流的方向。每一个操作的细节可以

28
通过移动鼠标指针到该操作的图标上显示出来。等价的信息可以在执行 SET 
SHOWPLAN_ALL ON 时，在基于文本的 showplan 上显示。要减少基于文本的查
询优化操作细节，请执行 SET SHOWPLAN_TEXT ON。

有关进一步的信息，请参见 SQL Server7.0 联机手册的下列主题或关键字：理解嵌
套循环连接（Understanding Nested Loops Joins），工作表（worktables）和
showplan。

Showplan 输出示 例
在 SQL 服务器查询分析器（SQL Server Query Analyzer）中使用前面的样本查询和
set showplan_text on 选项：

查询：
SELECT ckey1,col2 FROM testtable WHERE ckey1 = 'a' 基
于文本的 ShowPlan 输出：
|--Clustered Index Seek(OBJECT:([test].[dbo].[testtable].[testtable2]),
SEEK:([testtable].[ckey1]='a') ORDERED)
按照簇索引查找（Clustered Index Seek）的指示，这个查询利用了 ckey1 列上的簇
索引。

等价的图形 showplan 输出：

如果簇索引已经从表中删除，则查询需要扫描整张表。下面的 showplan 输出显示

了行为的改变：

基于文本的 showplan 输出：

29
 |--Table Scan(OBJECT:([test].[dbo].[testtable]), WHERE:([testtable].[ckey1]='a'))
等价的图形 showplan 输出：

30
表扫描是从较小的表中重新检索信息的最有效的方式。但在较大的表中，由
showplan 所显示的表扫描是一个警告，该警告提示表可能需要更好的索引或者目
前存在的索引一定要有统计的更新（通过使用 UPDATE STATISTICS 语句）。SQL 
Server7.0 提供自动更新索引的方法。由于索引的支持会帮助你保证查询将总是建立
在好的索引统计的基础上，因此你应该让 SQL Server 自动掌握索引统计。

查询：
SELECT nkey1,col2 FROM testtable WHERE nkey1 = 5000
基于文本的 showplan 输出：

31
 |--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([test].[dbo].[testtable]))
|--Index Seek(OBJECT:([test].[dbo].[testtable].[testtable1]),
SEEK:([testtable].[nkey1]=5000) ORDERED)
等价的图形 showplan 输出：

32
按照在 nkey1 列上的索引查找操作的指示，这个查询使用了建立在 nkey1 列上的非
簇索引。书签查找（Bookmark Lookup）操作指出，SQL Server 一定要执行一个从
索引页到表的数据页的书签查找，以取得需要的数据。因为查询所需要的 col2 列不
是非簇索引的一部分，因此，书签查找是必需的。

查询：
SELECT nkey1 FROM testtable WHERE nkey1 = 5000
基于
文本的 showplan 输出：

33
 |--Index Seek(OBJECT:([test].[dbo].[testtable].[testtable1]), SEEK:([testtable].[nkey1]=[@1])
ORDERED)
等价的图形 showplan 输出：

这个查询使用了 nkey1 非簇索引作为一个覆盖索引。因为非簇索引中提供了查询所

需的所有信息（SELECT 和 WHERE 子句），所以查询不需要书签查找操作。非簇
索引页中没有不需要数据页的书签查找。同需要书签查找的查询比较起来，I/O 大
大减少了。

性能 监控 器（ Performance Monitor）：
性能监控器提供了出现在数据库服务器上的关于 Windows 和 SQL Server 操作的信
息。有关 SQL Sever 的特定功能，请参见 SQL Sever 有关文档。

在性能监控器图形模式下，请注明最大最小值。不要太注重平均值，因为两极分化
的数据值将影响这个平均值。研究图形的形状并且同最大最小值比较，将得到对行
为的确切理解。利用 BACKSPACE 将会使计数器更加清楚。

你能用性能监控器把所有可用的 Windows NT 和 SQL Sever 执行监控对象和计数器

登记在日志文件中，并且能在表格模式下交互地显示性能监控器。设置采样时间间
隔将决定在多长时间内生成日志文件。日志文件可能增长很快（例如：如果启用所
有的计数器并且每十五秒钟登记一次日志文件，则在一小时之内将会有 100MG 大
的数据量）。这种测试服务应该有２ＧＢ的自由空间来存储这些日志文件，但是如
果要有大量的存储空间，则请试着用３０秒到６０秒这样比较大的日志登记间隔来
运行，这样性能监控器就不会过于频繁地检查这个系统，另外，所有的计数器也以
合理的频率进行采样，而日志文件将保持比较小的尺寸。

34
性能监控器也会占用一小部分的 cpu 和磁盘 I/O 资源。如果一个系统没有较多空闲
的 cpu 和 I/O 的磁盘资源，则可考虑从另一台计算机上运行监控程序，通过网络监
控 SQL Serve。这仅仅适用于监控程序的图形模式。当使用日志模式时，在 SQL 
Server 从本地登录监控程序会更有效。如果你必须通过网络使用日志模式，则可考
虑尽量缩减日志登记，仅仅在最关键的计数器上登记日志。

在性能监控器运行时，你应该把所有有用的计数器记录到一个文件中，以备今后分
析。请配置性能监控器，将所有的计数器记录到一个日志文件中，同时用一种其它
的方式（例如：图形模式）来监控所关心的计数器。然后，在执行程序运行时，所
有的信息都被记录下来，但是最有趣的计数器将显现在一张清楚有序的性能监控器
图形中。

⇒ 启 动日志 记录 （性能 监控 器）

1. 在菜单 View 中，点击 log 键。

2. 点击'+'键。
3. 在 Add to Log 对话框中，选择计数器以添加日志。
4. 点击 Add，然后点击 Done。
5. 在 Options 菜单上，点击 Log。
6. 在 File Name 一栏，键入一个文件名，执行信息将被记录在这个文件中。
7. 点击 Start Log.

⇒ 停 止日志 记录 (性 能监控 器)

1. 在 Options 上，点击 Log。
2. 点击 Stop Log。

⇒ 将 记录的 信息 置入性 能监 控器（ 性能 监控器 ）

1. 在 View 菜单上，点击 Log。

2. 在 Options 菜单上，点击 Data From，然后选择 Log File。
3. 点击 browse (…) 键，然后双击运行文件。
4. 在 Data From 对话框中，点击 OK。
5. 在 View 菜单上，点击 Chart，然后点击(+)键。
6. 点击有‘＋’标志的键。
7. 在 Add to Chart 对话框中，通过高亮 object/counter 在图形显示中增加所要的
计数器，然后点击 Add。

⇒ 及 时将性 能监 控器记 录的 事件放 到相 应的位 置上

1. 按照将信息放到性能监控器中的步骤进行。
2. 在 Edit 菜单上，点击 Time Window。

35
 3. 在 Input Log File Timeframe 对话框中，你可以通过在滚动条上点击并拖住
鼠标，调整记录数据的开始和停止时间窗口。
4. 点击 OK 键重新设置图表，仅仅显示设定时间内记录的数据信息。

关键 的性 能监 控器功 能
你能够观察性能监控器的磁盘计数器。要启用这些计数器，请运行 Windows NT 命
令窗口中的 diskperf­y 命令,并且重新启动 Windows NT 。这个 diskperf­y 命令确实
会消耗数据库服务器的一些资源，但是我们对所有 SQL Server 提供的产品运行
diskperf­y 命令是值得的，因为这样能立即确认磁盘队列问题。并且性能监控器计
数器可以立即用来诊断磁盘 I/O 问题。如果需要磁盘 I/O 次数计数器，则在磁盘 I/O
次数计数器向性能监控器提交数据之前，必须要执行 diskperf­y 命令，并且重新启
动 Windows NT 。

（ 物理或 逻辑 的）磁 盘队 列 > 2

具有磁盘队列的物理硬盘驱动器在保障 I/O 过程正常完成的同时，却阻碍了磁盘
I/O 请求。SQL Server 对这些驱动器的响应时间被拉长，所有这些将耗费查询执行
时间。

如果你使用 RAID,你必须清楚地知道每一个驱动器组中包含了多少物理磁盘驱动器
（Windows NT 将这些驱动器作为一个单独的物理驱动器），这样你就能计算每一
个物理驱动器的磁盘队列长度。询问一个硬件专家，让其解释 SCSI 通道和物理驱
动器分配以便理解每个物理驱动器是怎样容纳 SQL Sever 数据的，以及每个 SCSI
通道被分配了多少 SQL Sever 数据。

在性能监控器中可以查看磁盘队列有几种可选方式。逻辑磁盘计数器与磁盘管理者
（Disk Administrator）指定的逻辑磁盘相联系，而物理磁盘计数器则与磁盘管理者
把什么看成是单个物理磁盘驱动器密切相关。在磁盘管理者的眼中，单个的物理驱
动器可能是单个的硬盘驱动器，或者是包括几个硬盘驱动器的 RAID 组。Current 
Disk Queue 计数器是磁盘队列的即时测量值。然而,Average Disk Queue 计数器则是
把性能监控器采样时间内的磁盘排队测量值平均化所得的值。请注意下列情况的计
数器：

逻辑磁盘：平均磁盘队列长度大于２物理磁盘：平均磁盘队列长度大于２逻辑磁盘：
即时磁盘队列长度大于２

物理磁盘：即时磁盘队列长度大于２

每个物理硬盘驱动器都有特定的推荐量度单位。如果一个 RAID 组与一种磁盘队列

量度单位有关，那么这种量度单位必须按照 RAID 组中硬盘驱动器的数目进行分割，
以便决定每一个物理磁盘驱动器上的磁盘队列。

在包含 SQL Server 日志文件的物理硬盘驱动器或者 RAID 组中，磁盘队列并不是一

个有用的度量单位，因为 SQL Server 日志管理者不会向 SQL Server 日志文件中加
入一个以上的 I/O 请求。

有关进一步的信息，请参见 SQL Server 7.0 联机手册中的下列主题： 监控磁盘活动

（Monitoring Disk Activity）

系 统: 处理器 队列 长度 > 2 (每 个 CPU)

36
当这个计数器的值大于 2 时，服务器处理器接到的服务请求就会多得不能把这些请
求作为一组来处理，因此这时 Windows 必须将这些请求排成一个队。

排队等待处理器的现象意味着 SQL 服务器的 I/O 性能良好。如果没有排队现象而且

CPU 的利用率很低，那么这也许意味着系统中某些地方出现了性能瓶颈，最有可
能的是磁盘子系统。处理器队列中合理的工作量意味着 CPU 并没有在闲置，而且
系统的其他部分正在与 CPU 协调运作。

确定最佳处理器队列数的一个常用公式是将数据库服务器上的 CPU 数目乘以 2。

如果每个 CUP 的处理器队列长度远远大于 2，那么就应该检查一下原因。过长的处

理器队列会浪费查询执行时间。去除硬分页和软分页有助于节约 CPU 资源。其他
能够减少等待队伍长度的方法包括调整 SQL 查询、选用好的 SQL 索引以减少磁盘
的 I/O(进而减少 CPU 的工作)或者往系统中加入更多的 CPU(处理器)。

硬 分页 ­ Memory: Pages/Sec > 0 或 者 Memory: Page Reads/Sec > 5
Memory:Pages/Sec 大于 0 或 Memory:Page Reads/Sec 大于 5 意味着 Windows 正准备
到磁盘区去进行内存访问（硬分页错），这要耗费磁盘 I/O 和 CPU 资源。
Memory:Pages/Sec 计数器是 Windows 正在执行的分页数量和数据库服务器 RAM 配
置足够程度的良好指示器。在性能监控器中的硬分页信息子集是每秒钟 Windows
必须读取分页文件以解决内存访问问题的次数。Memory:Pages Reads/See 的值大于
5 是表示执行效率差。

自动的 SQL Server 内存调整能够动态地调节 SQL Server 内存的使用，从而可以避

免分页的产生。每秒内产生少量分页的也是正常的,但过多的分页就需要进行检查
了。

如果 SQL Server 能自动地调节内存，那么可以选择增加更多的 RAM 或从数据库服

务器中删除其它应用程序来使 Mmemory:Pages/Sec 计数器保持在合理的水平。

如果 SQL Server 内存正在被手工地配置到数据库服务器上，那么可能需要减少分
给 SQL Server 的内存，从数据库服务器上删除其它应用程序，或者给数据库服务器
增加更多的 RAM。

保持 Memory：Pages/Sec 等于或接近于零有助于数据库服务器的运行，因为
Windows 和它的所有应用程序(包括 SQL Server)并不是正在运行分页文件以满足内
存所需的所有数据。因此服务器的内存量是足够的。一个 Pages/Sec 的值略大于 0
并不可怕，但每次从分页文件中收回而不是从内存中收回数据时，就要付出相对较
高的运行代价(磁盘 I/O)。

你应该了解 Memory：Pages Input/Sec 计数器和 Memory: Page Reads/Sec 计数器之间

的差别。Memory:Pages Input/Sec 计数器表示导致分页错误的正从磁盘取出
Windows 4­kg 页面的实际数目。Memory:Pages Reads/Sec 计数器表示导致分页错误
的每秒内磁盘 I/O 请求次数，这提供了一个略微有点不同的观点。因此一个单独的
页面读取操作能包含多个 Windows 4kb 页。当成包的数据量(64KB 或者更多)在增
加时，磁盘 I/O 性能更好，因此同时考虑这些计数器可能很有价值。你也应该记住
对于一个硬盘驱动器，完成一个单一的 4KB 的读写操作所花时间差不多等于完成
一个单一的 64KB 的读写操作所花的时间。试想这样的情况：每次读 8 个 4KB 页的
200 页读取操作能够比每次只读一个 4KB 页的 300 页读取操作快。1600 个 4KB 页

37
 的读操作比 300 个 4KB 页的读操作更快。对所有磁盘 I/O 进行分析的关键点不仅仅
看磁盘的每秒读写字节数，而且看磁盘的每秒传送次数。有关进一步的信息，请参
见本文档后面部分的“磁盘 I/O 计数器”和“EMC 磁盘 I/O 调整介绍”。

把 Memroy:Page Input/sec 计数器和与 Windows NT 分页文件有关的所有驱动器的

logical disk:disk reads/sec 计数器相比较是有用的,而且把 Memory:Page output/sec 计
数器和与 Windows 分页文件有关的所有驱动器的 Logical Disk:Disk writes/sec 计数
器相比较也是有用的。它们提供了相对于其它应用程序（比如 SQL Server）而言，
在严格意义上有多少磁盘 I/O 与分页有关的尺度。另一种把分页文件 I/O 活动隔离
开来的的方法是保证分页文件位于一个独立于其他 SQL Server 文件中的装置上，
从 SQL Server 文件上隔离分页文件也有利于磁盘 I/O 性能，因为跟分页有关的磁盘
I/O 能与跟 SQL Server 有关的磁盘 I/O 平行运行。

软 分页­ Memory: Pages Faults/Sec > 0 
如果 Memory:Page Faults/sec 计数器大于 2，这就意味着 Widows NT 正在分页，但
计数器中包括硬分页和软分页，软分页意思是数据库服务器上请求内存页的应用程
序仍然驻留在 RAM 中，但不在应用程序工作集中。Memory: Page Fault/sec 计数器
有助于派生发生软分页的次数。没有一个计数器每秒都监测软分页错误。实际上，
用下面的方法计算每秒发生的软分页错误数目：
Memory: Pages Faults/sec - Memory: Pages Input/sec = Soft Page Faults per Second
要确定 SQL Server 是否正在引起过多的分页，应为 SQL Server 过程监视
process:page faults/sec 计数器并且记录下每秒 Sqiserr.exe 的分页错误数目是否与每秒
页的数目接近。

因为软错误耗费 CPU 资源，所以软分页错误在运行中优于硬分页错误。硬分页错

误耗费磁盘 I/O 资源，最好的运行环境是没有任何类型的错误。

直到 SQL Server 第一次使用它的所有数据缓存页后，对于每个页的初始化访问才会
引起一个软错误。如果软错误发生在这种情况下，不要着急。有关进一步的信息，
请参见本文档的“Monitoring Processors”。

有关内存调节的进一步信息，请参见 SQL Server Book Unline 中的以下主题：监控

内存使用（Monitoring Memory Usage）。

监控处 理程 序
使服务器所有的处理器保持足够的工作强度以使其性能达到最佳，但不能超负荷而
导致出现处理器瓶颈。性能调整所面临的挑战是要确定出现瓶颈的原因。如果瓶颈
不是因为 CPU，那么问题最有可能出在磁盘子系统，所以就会浪费 CPU 资源。
CPU 是最难扩展到高于特定配置水平（如许多现在流行的系统上的 4 个或 8 个的水
平）的资源，所以 CPU 利用率高于 95%是一个很好的现象。另外，应该控制处理
的回应时间以确保处理是合理的；如果处理不合理，那么高于 95%的 CPU 利用率
可能意味着工作负荷已经超过了现有 CPU 资源的承载能力，以至于需要将 CPU 升
级或者减少或调整工作负荷。

对 Processor:Proces Time%计数器加以控制以保证在每个 CPU 上所有的处理器的利

用率一致低于 95%。System:Processor Queue 是计算一个基于 Windows NT 的系统的
所有 CPU 的处理器队列的计数器。如果每个 CPU 的 System:Processor Queue 计数器
值大于 2，那么，就出现了 CPU 瓶颈，有必要往服务器中加入更多的处理器或者减
少系统的工作负载。可以与减少工作负载配合采用的方法还有查询调整或加强索引
以减少 I/O 次数，从而相应地减少 CPU 的使用。

38
当可能出现 CPU 瓶颈时，可以控制的另一个计数器是 System:Context Switches／
sec，因为它标志着每秒钟内 Windows NT 和 SQL 服务器不得不从执行一个进程转
而执行另一个进程的次数。上下文切换是多进程、多处理器环境的标准组成部分，
但是过多的上下文切换会降低系统的效率。只有当出现处理器队列时上下文切换才
会受到关注。当出现处理器队列时，则应用上下文切换作为调整 SQL Server 的标准。
应考虑使用 lightweight pooling 选项以使 SQL Server 从基于线程的计划模式转换到
基于光纤的计划模式。把光纤作为轻量级的线程。用 SP­configure lightweight 
pooling' 1 命令以支持基于光纤的计划。观察处理器队列和上下文切换以控制效果。

DBCC SQLPERF(THREADS)语句提供了更多与 SPID 有关的 I/O、内存以及 CPU 使

用的信息。

磁盘 I／O 次数计 数器
Disk Write Bytes／Sec 和 Disk Read Bytes／Sec 计数器提供各个逻辑驱动器每秒处理
的字节数。将这些数字与 Dbk Reads／Sec 和 Disk Writes／Sec 计数器的值仔细比较。
不要见到一个较小的每秒字节数就认为磁盘 I／O 子系统在闲置。一个单片硬盘驱
动器能够支持每秒总共 75 次无序的和 150 次有序的磁盘读写。

监控所有与 SQL Server 文件有关的驱动器的 Disk Queue Length 计数器并确定哪些

文件与多余的磁盘队列有关。

如果性能监控器显示出有些驱动器并不和其余几个驱动器一样繁忙，你可以将 SQL 
Server 文件从堵塞的驱动器转移到其它不怎么繁忙的驱动器去处理。这样就可把磁
盘 I/O 活动在各个硬盘驱动器间分配得比较平均。如果一个大的驱动器池被用来处
理 SQL Server 文件，那么比磁盘队列更好的解决方案是通过增加更多的物理驱动器
到这个池中以扩大这个池的读写能力。

磁盘队列的出现可能表示一个 SCSI 通道已经为 I/O 请求所饱和。如果真的出现了

这种情况，那么，性能监控器就不可能直接检测到这是否为真。硬件厂商可以提供
工具来检测正接受一个 RAID 控制器服务的 I/O 次数以及这个控制器是否正在处理
一个请求队列。这种情况当许多磁盘驱动器(10 个或更多)使用 SCSI 通道而且这些
驱动器都在全速运行的时候更可能出现。要解决这个问题，可取出一半的磁盘驱动
器并将它们连接到另一个 SCSI 通道或者 RAID 控制器上以分配 I/O 工作。在 SCSI
通道间重新进行分配需要重建 RAID 阵列并且备份和重装全部 SQL Server 数据库程
序。

39
 性 能监控 器图 形输出

这幅图显示了性能监控器用来观察服务器性能的典型计数器。正被观察的是处理器
队列长度计数器。点击 BackSpace 以突出现在被分析的计数器。这样有助于将该计
数器与其它正在被观察的计数器区别开来，并且，当利用性能监控器同时观察多个
计数器的时候，这种帮助就更加明显。

计数器的最大值（Max）可达 22.000。性能监控器图上的最大（Max）、最小
（Min）和平均值（Average）代表的只是如图所示时刻的图形时间（Graph Time）
窗口。图形时间（Graph Time）的缺省值是 100 秒。要想监控较长的时段并且确保
能得到这些时段有代表性的最大、最小和平均值，请使用性能监控器的日志特性。

图上处理器队列长度线的形状说明最大值 22 只出现了很短的一段时间。但是当处
理器最大长度大于 5 时有一个时段保持着 22 这个值，这一段是 100%，而且在 22
这个值之前当图形值大于 25%的时候有一个时段，这一段处理器最大长度的值约为
5。在这个例子中，数据库服务器 HENRTLNT2 只有一个处理器，而且不应承担大
于 2 的处理器最大长度。所以，性能显示这台计算机的处理器已经超负荷工作，而
且应该进行深入的检查以减少处理器的负担或者往 HENRYLNT2 加入更多的处理
器，以处理那些高工作负荷时段的工作。

本节列出了其他可以影响 Microsoft SQL Server 性
能的因素。
其他影 响性能的因 素

40
缓解 网络 交通 和资源 耗费
使用 SQL Server 的相对比较容易使用的接口——例如 Microsoft ActiveX Data 
Objects (ADO），Remote Data Objects (RDO)和 Data Access Objects (DAO)——的数
据库编程人员必须注意他们所构建的结果集。ADO、RDO 和 DAO 为编程人员提供
数据库开发界面，无需太多数据库编程经验就可以实现丰富的数据库行集合功能。
当编程人员既不用解释它们返回给客户的数据、也不用始终留意 SQL Server 的索引
放在什么地方以及 SQL Server 的数据是如何安排的时候，他就能解决性能问题。
SQL Server Profiler ，Index Tuning Wizard 和 Show Plan 是发现和解决查询问题的有
用工具。

寻找机会通过删除选择列表中没有必要返回的列，或通过仅返回所需要的行以减小
结果集的大小。这样可以减少 I/O 和 CPU 的耗费。

有关进一步信息，请参见 SQL Server 7.0 联机手册中的以下主题： 利 Optimizing 

Application Performance Using Efficient Data Retrieval（利用有效数据访问优化应用
程序性能），了解和避免阻塞（Understanding and Avoiding Blocking），
Application Design（应用程序设计）

死锁
如果已经建立了存取 SQL Server 的应用程序，从而事务以与所有用户事务同样的时
间顺序来存取表格，你或许可以避免死锁。在应用程序设计过程中，你应该尽可能
早地将存取的时间表解释给 SQL Server 应用程序开发人员，以避免死锁问题，因为
拖后解决这个问题的代价会非常昂贵。

减少 SQL Server 查询 I/O 和缩短处理时间有助于避免死锁。这样可以加快查询，锁

定也会被限制在一个较短的时间内，并且可减少所有的锁定问题 (包括死锁)。用
SQL Server Query Analyzer 中的 Show Stats I/O 选项来确定与大的查询相伴而来的逻
辑页的数目。用 SQL Server Query Analyzer 中的 Show query plan 选项来评价索引的
使用效果，然后考虑重新设计效率更高且使用更少 I/O 的 SQL Server 查询。

有关进一步的信息，请参见 SQL Server7.0 联机手册中的以下主题：避免死锁
（Avoiding Deadlocks），发现并解决死锁（Troubleshooting Deadlocking），检测和
解决死锁（Detecting and Ending Deadlocks），和模拟非串行化事务（Analogy to 
Nonserializable Transactions）。

查询 中要 避免 的语句
在 SQL 查询中使用不等值操作符迫使数据库使用表扫描来评价这些不相等的值。
如果这些查询用以频繁操作大表，它们将产生大量的 I/O。

例如，查询中使用带 NOT 的 WHERE 表达式：

WHERE <column_name> != some_value 如果你必须运行
WHERE <column_name> <> some_value 这些查询，请重
新构造查询语句以消除 NOT 关键字或操作符。

将下列语句：
SELECT * FROM tableA WHERE col1 != 'value' 换成语句：

41
 SELECT * FROM tableA WHERE col1 < 'value' AND col1 > 'value'
如果索引建立在 col1 上，而不是求助于表扫描，则 SQL Server 可以使用索引（尤
其是簇索引）。

灵活 的规 范化
在频繁访问的表中，可以将数据库应用程序不经常使用的列转移到另一张表。通过
删除尽可能多的列，你能够减少 I/O 次数，并且加强其性能。有关进一步的信息，
请参见 SQL Server 7.0 联机手册中以下主题：逻辑数据库设计和规范化（Logical 
Database Design and Normalization）。

分割 视图
你可以通过 SQL Server 7.0 中的视图来水平地分割表。这样，当数据库用户查询整
个视图的某个部分时，就能为 I/O 提供性能优化。例如，如果一张很大的表记录了
所有销售部门一年的销售情况，而从此表中提取数据时只是根据一个销售部门来提
取，则可以使用分割视图。为每一个销售部门定义一张销售表，每张表上的销售部
门栏定义一个限制条件，这样，就创建了一张基于所有表的视图以形成一张分割视
图。查询优化器在销售部门栏中使用已定义过的限制条件。当此视图被查询时，与
所提供的销售部门值不匹配的所有销售部门表都将被忽略，针对这些表的 I/O 也不
被执行。这样，通过减少 I/O 增强了查询性能。

有关进一步的信息，请参见 SQL Server 7.0 联机手册中的以下主题：视图使用说明
（Scenarios for Using Views），创建视图（CREATE VIEW），使用带分割数据的
视图（Using Views with Partitioned Data），通过视图修改数据（Modifying Data 
Through a View），复制或录入视图（Copying To or From a View），分割技术
（Partitioning）。

复制 和备 份性 能
如果你能确保磁盘 I/O 子系统和 CPU 运行良好，你就能确保所有 SQL Server 操作
执行情况良好，包括复制和备份。从事务日志文件中读入事务复制和事务备份日志。
快照复制和备份将执行一系列数据库文件扫描。SQL Server 存储结构使这些操作迅
速而有效，只要数据库服务器 CPU 或磁盘子系统没有发生排队等候。

有关进一步的信息，请参见 SQL Server 7.0 联机手册中的以下主题或关键字：优化
备份和存储性能（Optimizing Backup and Restore Performance），创建和存储不同的
数据库备份（Creating and Restoring Differential Database Backups），创建和应用事
务日志备份（Creating and Applying Transaction Log Backups），使用多媒体介质或
设备（Using Multiple Media or Devices），在任务关键的环境中最小化备份和恢复
次数（Minimizing Backup and Recovery Times in Mission­Critical Environments），备
份/恢复体系结构（Backup/Restore Architecture），大服务器上的 SQL Server（SQL 
Server 7.0 on Large Servers），复制性能（replication performance）。

42
EMC 磁盘 I/O 调节方 案
对于那些在单一 EMC Symmetrix 企业存储系统（EMC Symmetrix Enterprise Storage 
Systems）上使用的 SQL Server 数据库系统，一些磁盘 I/O 平衡方法可以帮助避免
磁盘 I/O 瓶颈，并且能够最优化性能。

Symmetrix 存储系统包含多达 16GB 的 RAM 缓冲池和磁盘队列的内部处理器，这些

处理器有助于加速 I/O 处理而无须使用主服务器的 CPU 资源。你必须了解
Symmetrix 存储系统的四个部件以平衡磁盘 I/O。部件之一是 16­GB 的缓冲池。最
多有 32 SA 通道可以被用以将 32 SCSI 插件从基于 Windows NT 的主服务器送入
Symmetrix；所有这些 SA 通道可以同时从 16­GB 缓冲池中请求数据。在 Symmetrix
存储系统中，有多达 32 个叫做 DA 控制器的连接装置（内部 SCSI 控制器），它们
可将 Symmetrix 中所有内部磁盘驱动器连入 4­GB 内部缓冲池。最后，Symmetrix 中
还有硬盘驱动器。

EMC 硬盘驱动器是带有与本文档所提到的其它 SCSI 驱动器相同 I/O 功能的 SCSI 硬

盘驱动器。EMC 技术通常有的一个称为 hyper­volumes 的特征。一个 hyper­volume
是一个 EMC 硬盘驱动器的逻辑部件，因此 hyper­volumes 看起来似乎是 Windows 
NT 硬盘管理器的另一个物理驱动器，它可以象其它驱动器一样被 Windows NT 磁
盘管理器操作。一个物理驱动器上可定义多个 hyper­volumes。在管理 EMC 存储数
据库性能调节时，你应该与 EMC 领域的工程师亲密合作，以确定 hyper­volumes 是
如何定义的。如果你认为两个或更多个 hyper­volumes 虽然是分开的物理驱动器，
但实际上是在同一物理驱动器上的两个或更多个 hyper­volumes，那么你可以装载一
个带有数据库 I/O 的物理驱动器。

SQL Server I/O 应该在不同 DA 控制器中平均分配，因为 DA 控制器被分配到了一套

确定的硬盘驱动器。DA 控制器可能不会遭遇瓶颈，但带有一个 DA 控制器的硬盘
驱动器可能更容易遭受损害。SQL Server 磁盘 I/O 平衡机制与 DA 控制器及它们所
连接的硬盘驱动器联系起来，其联系途径与它和其它销售商的磁盘驱动器、控制器
联系的途径相同。

为了监控一个 DA 通道或分开的物理硬盘驱动器上的 I/O，必须求助于 EMC 技术支

持人员，因为 I/O 行为发生在 EMC 内部缓冲池而不为性能监控器所见。EMC 存储
单元有内部监控工具，它允许一个 EMC 技术支持工程师监控 Symmetrix 中的 I/O 统
计数据。性能监控器只能看见从一个 SA 通道进出 EMC 存储单元的 I/O 情况。这足
以表示一个 SA 通道正在排队等候磁盘 I/O 请求，但还不足以决定是哪个或那些磁
盘造成的磁盘队列。如果 SA 通道正在排队，也许是磁盘驱动器而非 SA 通道造成
这种瓶颈。一种分辨是 SA 通道还是 DA 通道造成磁盘 I/O 阻塞的方法是在主服务器
上加一张 SCSI 卡，并将它连接到另一 SA 通道。如果性能监控器显示通过两个 SA
通道的 I/O 量没有改变，磁盘队列仍在发生，那么就不是 SA 通道造成的瓶颈。另
一种分辨方法是让一个 EMC 工程师使用 EMC 监控工具来监控 EMC 系统，辨认造
成瓶颈的驱动器或 DA 通道。

将 SQL Server 操作平均分配到尽可能多的磁盘驱动器上。如果你工作在一个承担

大量 I/O 的小型数据库上，应考虑让 EMC 技术工程师定义 hyper-volumes 的大小。
假设 SQL Server 将包括一个 30GB 的数据库。EMC 硬盘驱动器可提供多达 23GB 的容
量，因此你可以将整个数据库适配到两个驱动器上。就可操纵性和花销来说，这是
很吸引人的；但对于 I/O 的执行来说则不然。一个 EMC 存储单元可以同 100 多个内
部驱动器一起工作。若 SQL Server 只使用两个驱动器则会导致瓶颈。可考虑定义
更小的 hyper-volumes，比如每个 20GB。大约 12 个 hyper-volumes 可以与一个确
定的 23-GB 硬盘驱动器连接。假设存储此数据库需要用 2-GB 的 hyper-volumes，15
个 hyper-volumes。确保每个 hyper-volumes 连接一个分开的物理硬盘驱动器。不
要使得一个物理驱动器用 12 个 hyper-volumes 而另一个物理驱动器用 3 个 hyper-

43
 volumes，因为这与用两个物理驱动器（150 无序 I/O / 300 顺序 I/O 通过这两个驱
动器）是相同的。但对于 15 个 hyper-volumes（每个可连接单个的物理驱动器），
SQL Server 使用 15 个物理驱动器来提供 I/O（每秒 1125 无序/2250 顺序 I/O 操作
使用这 15 个驱动器）。

也可以考虑使用主服务器的几个 SA 通道来划分 I/O 工作，以支持多于一个的 PCI

总线，就象划分到 SA 通道上一样。考虑每个主服务器 PCI 总线使用一个 SA 通道，
象在 SA 通道间一样在 PCI 总线分配 I/O 工作。对于 EMC 存储系统，每个 SA 通道
连接一个固定的 DA 通道和一套固定的物理硬盘驱动器。因为 SA 通道从 EMC 内部
缓冲池读写数据，所以 SA 通道不可能是一个 I/O 瓶颈点。因为 SCSI 控制器瓶颈也
不可能，所以最好是密切注意平衡物理驱动器的 SQL Server 操作而非担心有多少
SA 通道可用。

Microsoft SQL Server 文档提供诸如 SQL Server 结构、带

完整控制语法和管理文档的数据库调整等众多信息。因
查找更 多的信 息 为 SQL Server 联机手册非常有用，所以应将它安装到经
常使用 SQL Server 的计算机硬盘上。

关于最新的 Microsoft SQL Server 信息，包括其它白皮书，请访问 Microsoft SQL 

Server 网站。网址是 www.microsoft.com/sql。

Compaq 已修改其 RAID 文档，它提供 50 页关于数据库服务器性能的最佳信息。文

档中的 Microsoft SQL Server 信息是指 6.5 版,它不适用于 7.0 版。此文档标题为
“Configuring Compaq RAID Technology for Database servers”，网址为
www.compaq.com/support/techpubs/whitepapers/ecgo11058.html。Compaq 文档号是
ECG011/0598。

Compaq 网址是 www.compaq.com/support/techpubs/whitepapers/ecgo250997.html，它

包含一个 30 页的名为“磁盘子系统性能和质量”的基于 Windows NT 的文档，它详
细描述了 Compaq 硬盘驱动器的硬件性能特征和物理驱动器行为。此文档包含的信
息适用于从 Compaq 或其它销售商处可得到的 SCSI 硬盘驱动器。此 Compaq 文档号
是 ECG025.0997。

由 JoeCelko 编著，Morgan Kaufmann 出版的 SQL for Smarties（版本号为 ISBN1­

55860323­9），解决了诸如描述和查询等级数据的一般问题。其中一章主要论述了
如何优化 SQL 查询。

44