数据库系统严重依赖服务器的资源：CPU，内存和硬盘IO，通常情况下，内存是数据的读写性能最高的存储介质，但是，内存的价格昂贵，这使得系统能够配置的内存容量受到限制，不能大规模用于数据存储；并且内存是易失性的，不能持久化存储数据，这使得内存只能作为运行时的高速缓存，而硬盘是永久存储数据的理想介质，价格低廉，在系统停电时，能够保持数据不丢失。但是，硬盘是低速的存储介质，输入和输出（IO）速度比内存低很多。因此，在实际运行的数据库系统中，相对于内存而言，硬盘的IO有更大可能性成为系统性能的瓶颈。
内存和硬盘都是存储资源和IO资源，由于内存的容量相对较小，IO速度快，因此，内存更有可能成为争用的存储资源；而硬盘容量大，IO速度快，因此，硬盘更有可能成为系统争用IO资源。SQL Server为了平衡存储和IO资源的争用，在把数据从硬盘读取到内存后，会把数据缓存到内存中，当重复访问数据时，不需要从硬盘，而是直接从内存中获取。由于这个机制，为系统配置足够多的内存可以最小化硬盘IO，因为硬盘读取数据的速度远远低于内存，所以，尽可能减少硬盘IO可以在很大程度上提供系统的性能。
一，硬盘IO的延时对于SQL Server数据库系统，限制查询响应的主要因素是硬盘的延时，根据硬盘的物理构造（磁道和扇区），延时可以分为寻道延时和旋转延时：
寻道延时：硬盘的物理刺头移动并定位到所需数据的时间，
旋转延时：硬盘旋转到所需数据的时间，通常用MB/S，或IO吞吐量来衡量
在OLTP系统中，数据更新操作较多，每次读取的数据量少，目标数据的位置相对随机（随机读写），因此，对于寻道延时要求更高，硬盘需要花费更多的寻道时间。
在DSS/DW系统中，事务的运行时间更长，数据相对静态，不常更新，读操作比写操作的要求更高，顺序读操作占比很高，因此，IO吞吐量更重要，可以通过硬盘的盘面来增加顺序访问的IO吞吐量。
二，根据WaitType侦测IO性能SQL Server引擎把IO作为一个资源来看待，在多任务的现代数据库系统中，同一时刻会接收到很多查询请求，每一个查询请求都需要申请系统资源（CPU、内存和IO），才能继续执行下去，然而系统的资源是有限的，当查询争用资源时，有些查询请求资源得到满足，顺利执行下去，有些查询请求的资源得不到满足，该查询就被阻塞，处于等待资源分配的状态。当出现IO性能问题时，查询语句会被硬盘IO阻塞，这使得执行计划被迫挂起（或阻塞）来等待资源，SQL Server通过DMV来显示系统运行的状态，用等待类型来表示不同的阻塞信息。
1，数据文件的IO
如果SQL Server 出现 IO 性能问题，那么在SQL Server 内部通过DMV sys.dm_exec_requests的wait_type，来反馈 IO 问题。如果查询请求的wait_type长时间处于PageIOLatch_XX，那么说明系统不能很快把数据读取到内存中。
PAGEIOLATCH_xx ：用于描述数据页的IO争用，说明系统正在从硬盘加载数据到内存的Buffer Pool中
当SQL Server 要去读或写一个Page的时候，首先会在Buffer Pool里寻找，如果在Buffer Pool中找到了，那么读写操作会继续进行，没有任何等待。如果没有找到，那么SQL Server 就会设置Wait_Type为PageIOLatch_EX（写）或PageIOLatch_SH（读），然后发起一个异步IO操作，将页面读入Buffer Pool中，在IO没有完成之前，Request将会保持在PageIOLatch_EX（写）或PageIOLatch_SH（读）的等待状态。IO消耗的时间越长，等待的时间越长。
2，日志文件的写入
日志文件以写为主，工作量由修改命令激发的事务数量决定。当SQL Server要写事务到日志文件时，如果Disk 不能及时完成IO请求，那么事务就无法提交，SQL Server 不得不进入WriteLog 等待状态，直到事务被成功记录到日志文件中，才会提交当前的事务。
如果request经常出现WriteLog的Wait type，说明事务日志的写请求不能被Disk及时完成，这种情况，对SQL Server 整体性能影响较大。
WRITELOG：在数据被修改时，在Log Cache和Buffer Cache中都会有记录，如果在Log Cache中的数据在checkpoint时写入硬盘，就会发生这种等待。
LOGBUFFER等待：很少出现，当一个任务正在等待存储日志到Log Buffer中时，就会出现LOGBUFFER等待，出现这种等待，说明日志所在的硬盘无法响应请求。如果把日志文件放在一个非常慢的硬盘上，而数据文件放在一个非常快的硬盘上，就会出现这种等待。
3，AYSNC_IO_COMPLIETION和IO_COMPLIETION也是IO瓶颈的潜在指标