我们经常遇到SQL Server数据库性能快速下降的情况。这种问题之所以会产生，CPU、内存资源的不足是其中的诱因之一。除此之外，经过技术人员的深入研究分析后发现，IO瓶颈也是导致SQL Server数据库出现性能问题的关键因素。

从工作机制层面，当SQL Server数据库持续不断的将内存页中的数据交换到缓冲池（buffer pool）外面时，IO子系统的性能问题就会浮出水面。另外，事务日志和TempDB（临时库）也会占用大量的IO带宽。这时作为运维人员，就必须及时的发现IO问题，否则这些IO问题所导致的响应延迟甚至时超时现象，将会直接影响到使用数据库的业务系统，并最终波及到业务人员。

那么如何定位IO问题呢？

在Windows操作系统中，Performance Monitor是一个发现IO问题的好工具。如何打开Performance Monitor呢？只要在Windows开始->运行中输入如下命令即可：

perfmon.msc /s

打开性能监视器，在右侧画线区域点击鼠标右键，点击“添加计数器”。

找到“PhysicalDisk”

展开该计数器分类，就可以看到它的子计数器了。

其中下面几个关键指标，可以作为分析Windows操作系统IO瓶颈的依据：

Avg. Disk Queue Length：这个指标展示的是在物理磁盘上读请求或写请求的队列长度。数值越大，说明有越多的磁盘操作处于等待状态。单磁盘驱动器情况下，在部署了SqlServer数据库的服务器上，如果这个数值长期大于2，就需要注意了。如果在您的服务器上，有多块物理磁盘，并且做了Raid，那么您可以将此队列长度除以磁盘驱动器的个数。例如，在服务器上插入了4块硬盘，而这个队列长度是10的话，计算队列长度时应该用10/4=2.5。即如果队列数超过2.5，则存在磁盘操作排队现象。

Avg.Disk Sec/Read，Avg.Disk Sec/Write：这个指标的意义是平均每次磁盘读写所耗费的时间。理想状态下，磁盘读写不应该超过10ms，但实际上只要不超过20ms，IO性能仍然是可以接受的。更高时，就需要考虑性能问题了。

%Disk Time： 这是个时间比例值，它标识了磁盘繁忙时间在整个磁盘读写请求周期内时间的占比。理想状态下，这个数值应当低于50%。

Disk Reads/Sec ，Disk Writes/Sec：磁盘每秒读写次数。这个数值不应当超过磁盘最大吞吐能力的85%。当超过此数值，磁盘访问时间将以指数级别增长。当然这个参考量，磁盘厂商通常不会提供。因此如果我们想要得到某块磁盘的最大吞吐量，只能借助基准测试工具（如IO Meter）。

在做了磁盘Raid的服务器上，通过下面的公式计算每块磁盘分摊的每秒磁盘读写数：

Raid 0: I/O per disk = (reads + writes) / number ofdisks

Raid 1: I/O per disk = [reads + (writes*2)] / 2

Raid 5: I/O per disk = [reads + (writes*4)] / number of disks

Raid 10: I/O per disk = [reads + (writes*2)] / number of disks

比如：对于RAID 1，如果得到下面的计数器：

Disk Reads/sec = 90

Disk Writes/sec =75

根据公式：[reads + (writes*2)] / 2 or [90 + (75*2)] / 2 = 120I/Os。即每个磁盘每秒钟分摊到120次IO操作。