工作线程
SQL Server 维护 Windows 线程池，该线程池用于维护正提交给数据库服务器的 SQL Server 批命令。可用来维护所有输入的批命令的线程总量（在 SQL Server 术语中称为“工作线程”）由 sp_configure 的 max worker threads 选项来规定。如果正在提交批处理的连接数量大于为 max worker threads 指定的数目，那么工作线程将在正在提交批处理的连接之间共享。默认的 255 可在大多数安装下正常运行。请注意大多数连接的大部分时间是在等待接收从客户机发来的批处理。
将脏的 8 千字节 (KB) 页从 SQL Server 高速缓冲存储器写出的任务主要由工作线程负责。工作线程将其 I/O 操作调度为异步，以获取最佳性能。
有关详细信息，请在 SQL Server Books Online 中搜索字符串“max worker threads option”、“sql server threads”、“Optimizing Server Performance Using Memory Configuration Options”、“sql server memory pool”、“Transaction Recovery”、“write ahead transaction log”和“Freeing and Writing Buffer Pages”。
LazyWrtier
SQL Server LazyWrtier 有助于生成可用的高速缓存区，即里面不包含任何数据的 8 KB 数据高速缓存页。在 LazyWrtier 将每一个 8 KB 高速缓存缓冲器刷新到磁盘时，需要对高速缓存页的标识进行初始化，以便其它数据可以写入可用的高速缓存区。LazyWrtier 的目的是在低磁盘 I/O 期间产生可用的高速缓存区，以便磁盘 I/O 资源可用，同时对其它 SQL Server 操作只有极小的影响。
SQL Server 7.0 自动配置和管理可用缓冲区的级别。监视“SQL Server: Buffer Manager-Free Buffers”以查看该值是否下降。最佳的方案是，LazyWrtier 在整个 SQL Server 操作中保持这个计数器级别，这意味着 LazyWrtier 可满足用户对可用高速缓存的需求。如果 Performance Monitor 对象“SQL Server: Buffer Manager-Free Buffers”达到 0 将很糟糕，这表示某些时候用户负荷的需求超过 SQL Server LazyWrtier 所能提供的可用高速缓存级别。
如果 LazyWrtier 在保持可用高速缓存稳定或至少大于 0 时遇到问题，可能意味着磁盘子系统无法为 LazyWrtier 提供它所需要的磁盘 I/O 性能。（将可用高速缓存级别下降与任意磁盘队列进行比较，以查看它是否正确。）解决方案是在数据库服务器磁盘子系统中添加更多的物理磁盘驱动器（通常也称为“驱动轴”），以增强磁盘 I/O 处理能力。“SQL Server: Buffer Manager-Lazy Writes/sec”表示正在物理上写入磁盘的 8 KB 页的数量。
通过查看（Logical 或 Physical）Disk: Average Disk Queue 或 Current Disk Queue 的计数器来监视 Performance Monitor 中磁盘队列的当前级别，并确保与任何 SQL Server 活动相关的每个物理驱动器的磁盘队列都小于 2。对于使用硬件 RAID 控制器和磁盘阵列的数据库服务器，需记住将 Logical/Physical Disk 计数器所报告的数目除以与逻辑驱动器号相关的实际硬盘数或物理硬盘数目（由磁盘管理程序报告），因为 Windows 和 SQL Server 都无从知道附加到 RAID 控制器上的物理硬盘的实际数目。很重要的一点是了解与 RAID 阵列控制器相关的驱动器的数目以便正确地解释 Performance Monitor 所报告的磁盘队列的数目。
使用 max async I/O 调整 LazyWrtier 磁盘 I/O 请求行为。sp_configure 的 max async I/O 选项控制 SQL Server 可同时提交给 Windows，然后 Windows 又提交给磁盘 I/O 子系统的 8 KB 磁盘写请求的数目（包括 LazyWrtier、Checkpoint 和工作线程发来的写请求）。如果磁盘队列的级别无法接受，应减小 max async I/O。如果要求 SQL Server 必须维持 max async I/O 当前配置的级别，应向磁盘子系统中添加更多的磁盘，直到磁盘队列降到可接受的级别为止。
有关详细信息，请在 SQL Server Books Online 中搜索字符串“freeing and writing buffer pages”和“write-ahead transaction log”。
Checkpoint
Checkpoint 将脏页写入 SQL Server 数据文件。脏页是自进入高速缓冲存储器后已被修改过的高速缓冲存储页。由 Checkpoint 写入磁盘的缓冲器仍然包含脏页，用户可以读取或更新它，而无需重新从磁盘读取，对于 LazyWrtier 所创建的可用缓冲区则不能如此。
Checkpoint 的目的是使工作线程和 LazyWrtier 从事大部分写出脏页的工作。具体的实现方法是，在写出脏页之前，如果可能，尝试额外的检查点等待。这将为工作线程和 LazyWrtier 提供更多时间以写出脏页。SQL Server Books Online 的“Checkpoints and the Active Portion of the Log”部分详细列出了在哪些条件下需要为脏页花费额外等待时间。请记住 Checkpoint 的主要目的是，通过这种额外的检查点等待，使 SQL Server 磁盘 I/O 活动在一段较长时间内比较均匀。
当有大量的页从高速缓存中清空时，为使 Checkpoint 更有效，SQL Server 将按照要清空的数据页在磁盘中的顺序对这些页排序。这有助于在高速缓存清空时最大限度地降低磁盘取数臂的运动量，并可能利用有序磁盘 I/O。Checkpoint 还将 8 KB 磁盘 I/O 请求异步提交给磁盘子系统。这使 SQL Server 得以更快地完成所需磁盘 I/O 请求的提交，因为 Checkpoint 不等待磁盘子系统向回报告数据已写入磁盘。
很重要的一点是监视硬盘上与 SQL Server 数据文件相关的磁盘队列，以留意 SQL Server 向下发送的磁盘 I/O 请求是否超过磁盘所能处理的磁盘 I/O 请求，如果是，则必须增加磁盘子系统的磁盘 I/O 容量，以便其能处理这样大的负荷。
使用 max async I/O 调整 Checkpoint 的脏页清空行为。sp_configure 的 max async I/O 选项控制 Checkpoint 可同时提交给 Windows（Windows 然后又提交给磁盘 I/O 子系统）的 8 KB 高速缓存清空的数量。如果磁盘队列的级别无法接受，应减小 max async I/O。如果要求 SQL Server 必须维持 max async I/O 当前配置的级别，应在磁盘子系统中添加更多的磁盘，直到磁盘队列降到可接受的级别为止。
另一方面，如果有必要提高 SQL Server 执行 Checkpoint 的速度，并且磁盘子系统强大到足以处理增加的磁盘 I/O，同时避免磁盘队列，那么请增加 max async I/O 使 SQL Server 一次发送更多的磁盘 I/O 请求，从而潜在地改善 I/O 性能。在改变了 max async I/O 后仔细查看磁盘队列计数器。除了要查看磁盘写队列之外，还需查看磁盘读队列。如果 max async I/O 的值对于某个磁盘子系统来说太高，Checkpoint 可能会将大量的磁盘写 I/O 请求排队，从而引起 SQL Server 读活动堵塞。DBCC PERFMON 将 Reads Outstanding 作为其输出提供出来，Reads Outstanding 是在 Performance Monitor 中进行监视以寻找排队的 SQL Server 读活动的有效计数器。Performance Monitor 中的 Physical Disk 对象和 Logical Disk 对象提供 Average Disk Read Queue Length 计数器，还可用它来监视排队的磁盘读 I/O 请求。如果磁盘读取队列是由 Checkpoint 引起的，那么或者减小 max async I/O，或者添加更多的硬盘，以便同时处理检查点和读请求。
Log Manager
像其它主要关系数据库管理系统 (RDBMS) 产品一样，SQL Server 确保在其联机状态被中断的时候（如断电、磁盘驱动器故障、数据中心发生火灾等等），数据库上执行的所有写活动（插入、更新和删除）都不会丢失。保证可恢复性的一个措施就是 SQL Server 日志记录过程。只有在 SQL Server Log Manager 从磁盘子系统收到信号，与事务相关的所有数据更改已成功写入相关的日志文件之后，所有隐式（单个 SQL 查询）或显式事务（所定义的发布 BEGIN TRAN/COMMIT 或 ROLLBACK 命令序列的事务）才能完成。这一规则保障了在 SQL Server 由于任何原因突然关闭而写入数据高速缓存的事务还未刷新到数据文件的情况下（请记住刷新数据缓冲器是 Checkpoint 或 LazyWrtier 的责任），在重新打开 SQL Server 后可以读取事务日志，并将它应用到 SQL Server。服务器中断后读取事务日志并将它应用到 SQL Server 的过程称为恢复。
因为在完成每个事务后，SQL Server 都必须等待磁盘子系统完成 SQL Server 日志文件的 I/O，所以对于容纳 SQL Server 日志文件的磁盘来说，具有足够的磁盘 I/O 处理容量以处理预计的事务负荷是很重要的。
监视与 SQL Server 日志文件相关的磁盘队列的方法与 SQL Server 数据库文件不同。使用性能监视计数器“SQL Server: Databases : Log Flush Waits Times”和“SQL Server: Databases : Log Flush Waits/sec”来检查是否有日志写入器请求等待磁盘子系统完成。
如果某一高速缓存控制器可以保证所有委托给它的数据最终都将写入磁盘，即使断电也是如此，则将该控制器用于 SQL Server 日志文件不会有任何问题。有关高速缓存控制器的详细信息，请参见本文后面的“硬件 RAID 控制器的插件高速缓存的效果”部分。
有关详细信息，请在 SQL Server Books Online 中搜索字符串“Transaction Recovery”、“SQL Server: Log Manager Object”和“optimizing transaction log performance”。
Read-Ahead Manager
SQL Server 7.0 Read-Ahead Manager 可完全自配置和自调整。Read-Ahead Manager 与 SQL Server 查询处理器紧密集成在一起。查询处理器将可能从预读扫描中受益的情形传递给 Read-Ahead Manager。大型表的扫描、大型索引范围的扫描以及聚集索引和非聚集索引 B 树的探测是可能从预读中受益的情形。这是因为预读可通过 64 KB I/O 进行，也就是说可为磁盘子系统提供比 8 KB I/O 更高的磁盘吞吐量。当需要从 SQL Server 检索大
