Wait--常见的等待类型
--==================================================================================
--SLEEP_BPOOL_FLUSH
MSDN上如是说：当检查点为了避免磁盘子系统泛滥而中止新 I/O 的发布时出现。
场景：
在做以下操作时
1. 在修改数据库属性，如修改还原恢复模式简单为完整，长时间不能运行完毕
2. 还原数据库时，消息提示100% 但是在运行
经过调查，发现等待为SLEEP_BPOOL_FLUSH，进一步调查，发现该数据库上及其容易产生脏页(修改1W条记录可能会照成2W的脏页)
解决办法：
1. 将数据量较大的表和索引拆分(或分区)或归档历史数据
2. 建立合适索引或修改索引字段顺序
--==================================================================================
--LCK_M_XX
由于资源被加锁而导致其线程因锁不兼容造成阻塞
造成的原因
1>不合理的事务隔离级别
2>过大的事务长期占有某些资源
3>执行效率不高的语句
解决方案
1>设置合理的事务隔离级别
2>使用乐观并发
3>读写分离
4>优化DML语句,建立合理的索引
5>避免使用不合理的锁提示
6>查找造成阻塞的其他原因
--==================================================================================
--PAGELATCH_XX
等待访问内存中的页面
PAGELATCH_XX与PAGEIOLATCH_XX完全不同
解决TempDB上的PAGELATCH_XX方案
1>启用TF 1118 来阻止将新创建的表放入混合区
2>增加文件个数来减少对系统分配页的争抢
3>不要显示Drop临时表来减少非非配页的争抢(存储过程中的临时表可以被重用)
解决页拆分引起的问题
1>GUID类型的索引键造成的页拆分,设置合适的填充因子或修改GUID键
2>数据变化过大引起的页拆分,将变化较大(长度)且变化频率较高的列拆分到其他表
3>控制索引键的长度
解决高并发插入自增表导致的插入热点
1>使用随机或组合键来将数据分散到表中各个部分而不是尾部
2>修改架构,将数据插入到多个表中或多个数据库中
--==================================================================================
--WRITELOG
等待将日志快flush到日志文件
可能原因
1>导致大量事务日志的操作产生，如果索引维护
2>事务并发度较高
3>IO系统瓶颈
4>频繁页拆分
解决方案
1>查看LOGBUFFER等待，是否存在对日志缓冲区的争抢
2>查看日志所在磁盘是否存在队列
3>查看事务平均大小，是否存在小事务频繁操作，将小事务合并为大事务
4>删除无用索引
5>业务拆分，由多个数据库来承担压力
6>提高日志磁盘的性能
7>修改索引，减少页分裂
--==================================================================================
--ASYNC_NETWORK_IO
当返回查询结果给客户端时，客户端未能及时处理
可能原因
1>网络不佳导致传输速率低
2>客户端程序处理数据存在问题
3>服务端返回过多数据
解决方案
1>修改客户端程序，避免出现RBAR(Row by agonizing Row)
2>避免一次返回给客户端过多数据，如果分页等
3>检查网络路由
4>检查网络硬件
--==================================================================================
--PAGEIOLATCH_XX
常见的有PAGEIOLATCH_SH和PAGEIOLATCH_EX,在数据页从磁盘读取到内存中发生等待，SH表示数据页用于读取，EX表示数据页用于修改
可能导致的原因
1>IO系统的确存在问题,存在IO瓶颈
2>执行计划不佳导致扫描
3>内存存在压力导致页在内存中的存活时间过短
解决方案：
1>检查执行计划
2>检查是否存在内存压力
3>检查是否存在其他应用导致IO压力
4>检查存储是否满足需求
--==================================================================================
--CXPACKET
在执行并行查询计划时，由于各并行线程之间任务分配不均匀或某个线程被阻塞，导致CXPACKET 值增加
导致CXPACKET等待高的原因有很多，不能盲目地修改 MAXDOP的值或修改实例级别的最大并发度
可能原因有：
1>统计过期导致生成低效的执行计划
2>缺乏索引导致表扫描
3>中间结果集无法预估结果集行数，导致执行计划低效
4>某个线程因其他资源被阻塞
解决方案
1>检查执行计划是否高效
2>修改语句的并发度
3>修改实例级别的最大并发度
补充：
建议将MAXDOP的值设置为小于逻辑CPU的数，以避免单个查询阻塞所有请求
