总体系统性能可能在 I/O 处理中扮演关键的角色。在研究延迟或阻塞 I/O 的报告时，应该考虑系统的综合运行状况。过多的负载可能导致整个系统（包括 I/O 处理）变慢。系统在发生问题时的行为可能是确定问题根源的关键所在。例如，如果 CPU 利用率在发生问题时变高或者保持较高水平，则可能表明系统中的某个进程正在消耗如此之多的 CPU 时间，以至于它以各种方式对其他进程产生了消极影响。

　　请查看性能计数器 Average Disk Sec/Transfer 以及 Average Disk Queue Length 或 Current Disk Queue Length，以获得特定的 I/O 路径信息。例如，SQL Server 计算机上的 Average Disk Sec/Transfer 通常低于 15ms。如果该值上升，则可能表明 I/O 子系统无法满足 I/O 要求。

　　请记住，SQL Server 充分利用了 Windows 的异步 I/O 功能，并且猛烈地扩展磁盘队列长度，因此上述性能计数器具有较高的值本身并不表明存在问题。


索引和并行性

　　特别常见的一种情况是，因为索引丢失以及由此导致的扫描、哈希和排序对 I/O 系统造成的压力，所以突发大量的 I/O。运行一遍“Index Turning Wizard”通常会有助于解决系统的 I/O 压力。如果添加索引可以帮助查询避免表扫描甚至排序或哈希，则系统可以获得多个优点：

　　减少完成操作所需的物理 I/O，这直接等效于提高查询的性能

　　数据缓存中只有较少的页面必须周转，因此缓存中的那些页面可以一直与活动查询相关

　　避免不必要的排序和哈希

　　可以降低 tempdb 利用率和减少争用情况

　　减少资源利用率和/或并行操作。因为 SQL Server 不能保证服务器在确定是否将查询并行化时考虑并行查询执行和系统中的负载，所以您最好针对串行执行优化所有查询。在 Q/A 环境中，应该将 max degree of parallelism 设置为 1，以便对根本没有从服务器收到任何并行计划的最糟糕情况强行进行调整。如果在测试环境中证实查询可以按串行方式高效执行，则生产环境中的并行计划可以提供出乎意料的性能改进。但是，很多情况下，SQL Server 选择并行执行，这是因为要遍历数据的绝对数量过于庞大。该数据量通常直接受到索引的影响。例如，如果丢失索引，则可能产生大量排序操作。我们很容易就可以看出，执行排序操作的多个辅助进程如何使响应速度比以串行方式处理排序更快速，不过我们需要了解，该操作可能大幅增加 I/O 系统的压力。当多个辅助进程并发运行时，来自多个辅助进程的大型读请求可能导致 I/O 突发以及 CPU 利用率提高。很多时候，如果添加了索引或者发生了其他调整操作，则可以调整查询以使其更快地运行并使用更少的资源。这不仅提高了相关查询的性能，而且还提高了系统的整体性能。



来自 Microsoft SQL Server Support 的实际示例

　　Microsoft SQL Server 和 Platforms Escalation Support 已经处理了下列方案，这些方案旨在提供一个参考框架，并且帮助树立有关延迟和阻塞 I/O 情况以及系统可能如何受到影响的预期。不存在给其他软硬件带来任何特殊或更高风险的特殊硬件或驱动程序集；在这个方面，所有系统都是相同的。

　　示例 1 — 阻塞 45 秒钟的日志写操作

　　一个尝试性的 SQL Server 日志文件写操作周期性地阻塞 45 秒钟。该日志写操作无法及时完成，从而产生阻塞情况，导致 30 秒钟的客户端查询超时。

　　请求被提交并阻塞（日志写挂起），导致查询继续占用锁并且阻塞来自其他客户端的传入请求。其他客户端开始超时并且使问题变得复杂，这是因为应用程序没有被设计为在发生超时的时候回滚尚未解决的事务。这会导致数以百计尚未解决的事务占用锁以及严重的阻塞。应用程序使用连接池来维护 Web 站点，因此，随着更多的连接被阻塞，Web 站点创建了更多的连接，而这些连接又会被阻塞，该循环会一直持续下去。

　　在大约 45 秒钟之后，该日志写操作将完成，但到此时为止，数以百计的连接已经积累起来，从而导致阻塞问题，并使得 SQL Server 和应用程序需要花费几分钟的时间进行恢复。当与应用程序问题结合起来的时候，延迟 I/O 状况会对系统产生非常消极的影响。