第1个回答 2020-10-07
一，硬盘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瓶颈的潜在指标
AYSNC_IO_COMPLIETION：标识任务正在等待IO请求来完成操作，当一个应用程序连接SQL Server，在处理数据时变得非常慢，很可能就会出现这种类型的等待。
IO_COMPLIETION：发生在一个任务正在等待用于非数据页IO的IO操作上，非数据页，一般是指日志文件，通常发生在修改大量修改，或者内存中存在大量的脏数据时。
三，影响读写性能的因素
数据库系统对IO的性能依赖较高，那么影响数据库系统读写性能的因素有哪些呢？
1，物理硬盘的IO能力
机械硬盘的IO速度没有固态硬盘快，可以考虑把数据库系统的机械硬盘更新为固态硬盘。
2，内存对硬盘IO的影响
在SQL Server Engine 访问数据时，如果相应的data不存在于Buffer Pool，那么Buffer Manager 从Disk中的Data File（mdf 或 ndf）中将相应的data page读取到内存中。SQL Server 将data page缓存起来。理想情况下，只要SQL Server能够使用的内存充足，SQL Server 会将所有读取到内存的中Data Page缓存到Buffer Pool中。对于读取操作，只要相应的数据都缓存在内存中，Select 就不会有任何硬盘IO。
当Buffer Pool空间不足时，SQL Server 激活 LazyWriter，主动将内存中一些很久没有使用的Data Cache和 Plan Cache 清除，mark为Free buffer，供其它Data Page使用。如果这些Page上的修改还没有被CheckPoint写回Disk，那么LazyWrite会将其写回。
3，碎片和压缩
如果数据页面或index 页面的碎片很多，每个页面存储的数据行较少，那么SQL Server 需要读写更多的Page。如果数据在页面里存储的非常紧凑，存储相同数据所消耗的Page越少，并且可以充分利用SQL Server 预读的优势，减少IO。
压缩技术不仅使数据占用的Disk 空间减少，而且能够减少IO。由于数据在写入Disk之间经过压缩处理，存储相同数据所消耗的Page减少，读取的Data Page会减少。压缩技术在一定程度上能够降低IO，但需要付出一定的代价：额外消耗少量的CPU和内存来解压缩。
4，利用多个物理硬盘实现Data File的并发读写
在DB中的FileGroup 创建多个File，将这些File存放到不同的Physical Disk上。File 分布到不同的Physical Disk上，IO也会分布到不同的Physical Disk上，这样能够实现数据的并发读取，提高读取性能。
对于日志文件，SQL Server会频繁的写事务日志。只要数据库发生修改，就会不断地写入日志文件。如果不能及时完成日志文件的IO，会导致事务的延迟提交，对性能的影响较大，所以，尽量将日志文件放到写入速度快的Disk上。SQL Server 顺序写事务日志，在一个时间点，SQL Server 只会写一个日志文件。在不同的Physical Disk上创建多个log file对性能基本没有帮助。
5，工作负载
日志文件以写为主，工作量由修改命令申请的事务数量决定，日志文件是顺序写的，写入速度快于随机写。如果日志记录不能及时写入，那么Request会处于WriteLog等待状态，对系统整体性能影响较大。
数据文件写入的数据量由修改量决定，SQL Server除了设置bulk logged 恢复模式之外，没有太大的调整选项。
数据文件读取的数据量，由访问的数据量和Buffer Pool中缓存的数据量共同决定。如果访问的数据量减少或者内存缓存区增加，都可以降低SQL Server 从Physical Disk读取的Data Page数量。在内存不变的情况下，可以通过优化查询语句，减少数据访问量，来提高SQL Server 数据文件的读取性能。