本篇文章的目的就是为帮助DBA，开发人员以及其他与使用数据库的人员阐述什么是数据库等待队列。

　　性能优化的已经变得越来越重要了，随着SQL Server 2005推出之后，里面包含了很多的动态管理视图（DMV）和函数，所以，我们很有必要如何使用这些动态管理对象来帮助我们进行性能的诊断与排除。

　　对于性能而已，我们一个最可以感知的现象就是：SQL Server的响应变慢了，而且服务器的资源开始被不正常的消耗。面对这些问题，分析等待队列是我们的第一步，只有知道数据库为什么慢，为什么耗费过多的资源，我们才能对症下药。

　　在接下来的内容中，将会讲述如何分析OLTP应用中的等待队列。当然，大家在此基础之上进一步的去研究和深入的学习。

　　在此之前，我们来看看与性能相关的几个内容，这样便于我们后续内容的展开，首先说说什么是总体的响应时间。

　　总体响应时间介绍

　　大家知道，在SQL Server 2000及之前的版本中，我们必须采用很多类似广撒网的方式来设置很多不同的计数器和工具来捕获和分析发生性能瓶颈的原因。我们常常使用的工具包括profiler traces，性能计数器，网络嗅探器，还有一些第三方的诊断工具。不可否认，使用这些工具可以帮助我们找到问题的症结，但是所花费的时间和精力都是非常多的。

　　我们常常会问这样的问题：数据库引擎在等待什么，从而导致性能下降？，其实，当我们使用工具来分析性能问题的时候，就是在试图去找出这些答案。另外，当我们把问题解决之后，最终用户最为关注的结果就是：总体的响应时间是多少，或者说，发送的查询的响应时间是多少。

　　所谓总体的响应时间，就是发送一个请求之后，一直到接收到响应，这个过程的时间。例如，现在用户通过应用程序发送了一个请求给数据库，去获取数据。那么总体的响应时间就如图所示：

　　其实，从严格的意义上说，总体响应时间还包含数据发送给应用程序之后，应用程序处理数据，展示数据花的时间，但是，我们这里的重点是研究数据库的等待，所以，我们就不考虑应用程序方面的时间问题。

　　下面就言归正传，我们来看看等待的问题。

　　什么是等待统计数据

　　采用微软官方的说法就是：当在SQL Server内部产生 一个请求的时候，由于某些原因，这个请求不能被立刻的处理，于是系统就让这个请求进入等待的状态。SQL Server内部的引擎会跟踪请求等待所花的时间，并且在这些等待的时间基于数据库实例进行聚合，并且把这些信息保存在内存中。

　　可能上面的讲法有点生硬，我们就举个简单的例子。如，当我们运行一个查询的时候，SQL Server由于CPU或者其他资源被占用而无法及时的处理我们的查询请求，那么此时，我们的请求就必须要等那些资源被释放之后才能继续进行。在这段期间，我们的查询请求就会被挂起，被放在等待队列中，并且SQL Server内部引擎中回去保存一些记录，来标示这个查询请求的等待类型，或者说，因为什么而导致了等待。

　　大家可以看看下面的图：