转载

SQL Server里等待统计（Wait Statistics）介绍

在今天的文章里我想详细谈下SQL Server里的统计等待（Wait Statistics），还有她们如何帮助你立即为什么你的SQL Server当前很慢。一提到性能调优，对我来说统计等待是SQL Server了最重要的概念。

查询为什么等待

在SQL Server里每次你执行1个查询，查询总需要等待。什么？查询总需要等待？是的，你没有看错：但给你执行1个查询时，查询总需要等待。为什么查询需要等待的原因是SQL Server通过所谓的等待统计（Wait Statistics）来跟踪的。在我进入等待统计（Wait Statistics）细节内容前，我想谈下SQL Server里查询总需要等待的原因。在SQL Server里查询发生等待有2个原因：

资源等待
协同调度（Cooperative Scheduling）等待

我们来详细看下这2类等待。当你等待外部资源时会发生资源等待（Resource Wait）。这里我想你一些例子。每次一个查询从缓存池请求1个页时，如果这个页没被缓存的话，缓存区管理器需要到你的存储进行异步I/O操作，从你的物理存储读取页到缓存池。而且访问物理存储会非常慢。由于这个原因SQL Server会拿掉你查询的CPU周期，查询只会等待直到异步I/O操作完成（同事其它查询可以更有效的使用CPU资源）。最后你的查询继续它的执行。

当你需要获取锁时也会发生同样的事情——当你想要读或修改数据时。当其它人已经获得了不兼容的锁，你的查询需要去等待直到锁可以获得。同时SQL Server会再次拿掉你的CPU周期，查询需要去等待直到其它查询的不兼容锁释放掉，这样的话查询本身可以获得请求的锁。

除资源等待外，SQL Server查询还会因SQLOS（SQL Server操作系统（OS））内部实现的协同调度（Cooperative Scheduling）而等待。SQL Server绕过Windows系统的抢占式调度（Cooperative Scheduling），调度它的线程本身。因为这样的设计SQL Server会更容易扩展，并为你提供更好的吞吐量。当1个查询在CPU上积极运行时，SQL Server本身就可以决定，当1个查询从CPU上拿掉时，SQL Server也可以决定，这样的话另1个查询可以在那个CPU上活跃继续它的查询执行。由于这个原因，一旦查询溢出所谓的量（Quantum），SQL Server就会把你的查询从CPU上拿掉。

量定义了查询在CPU上可以活跃花费的时间片（time slice）。在SQL Server里这个时间片是4毫秒长。这就是说一旦查询完成它的工作超出4毫秒，SQL Server就会把你的查询从CPU上拿掉。因此在SQL Server里查询总是要等待。如果没有资源等待，溢出量就会踢入，查询会在CPU上睡着（going off）。你的查询总会等待！

查询生命周期

我们我们知道了在SQL Server里查询总需要等待。我们来进一步看下它。当你执行1个查询，这个查询会进入3个不同的状态，如下图中所示：

SQL Server里等待统计（Wait Statistics）介绍

我们来详细说下这3个状态。只要你的查询在你的CPU上积极运行，这个查询是在 RUNNING 状态。 RUNNING 状态意味着你的查询当前正进行一些工作。进入这个状态一直是你的首要目标。当SQL Server把你的查询从CPU上拿掉时，然后这个查询移入了 SUSPENDED 状态。查询只要 SUSPENDED 状态需要都会等待，直到请求的资源可用（回想下从你物理存储读取的页，或者不能立即获得的不兼容锁）。

当请求的资源可用时，然后SQL Server把你的查询移入RUNNABLE状态。RUNNABLE状态意味着你的查询准备好了继续执行，但它需要另外必需的东西：在它上面运行的CPU。当现在没有可用的CPU时（因为其它查询当前在RUNNING状态），查询需要在RUNNABLE状态花费一些时间。最后当CPU变成可用时，查询移入RUNNING状态，然后一切轮回继续。一个简单的查询在执行期间，可以运行上几百次，甚至几千次的查询生命周期（query life cycle ）。

分析等待统计（Wait Statistics）

所有这些状态事务被SQL Server跟踪，并通过等待统计反馈给我们。SQL Server通过DMV sys.dm_os_wait_stats 来披露这些等待统计（Wait Statistics）。从这个DMV返回的每条记录都是SQL Server里的1个等待原因。在SQL Server 2014里你共有771个不同的为什么查询会等待的原因。什么？771个不同原因？跟我开玩笑吧？那是很多的！没错！但一般来说你只需要处理一些特定的等待原因，因为我们每个人几乎都处理SQL Server里同样的性能问题：

缓慢的存储子系统
不好的索引设计
锁/阻塞问题
低效的并行执行计划
CPU压力
……

当在面前有一个运行慢的SQL Server，第一步我总看下等待统计里的详细信息，因为它们告诉我为什么SQL Server里查询在等待。但SQL Server里的等待统计只是个症状，不是问题根源本身！或许SQL Server通过等待统计告诉你在过去有一些因阻塞情形的等待。但可能是不是你有一个不好的索引设计，缺失了一个非常重要的非聚集索引导致了阻塞情形？有了额外的非聚集索引你提供SQL Server额外的数据访问路径，是否你的阻塞情形就可以轻松解决？这只是症状并非根源的1个例子（很多中的）。