SQL Server 进程运行状态解析

SQL Server 中一些最常见的 SPID 状态及其含义：

RUNNING:

此状态表示会话正在运行一个或多个批处理。启用多活动结果集 (MARS) 后，一个会话可以运行多个批次。这实际上意味着，使用此会话连接到 SQL Server 的客户端已经提交了 SQL Server 要处理的查询，并且 SQL Server 当前正在处理该查询。查询可以在生成解析器树到执行连接以对数据进行排序之间的任何地方......并且它当前正在消耗 CPU（处理器）。

SUSPENDED:

这意味着该请求当前处于非活动状态，因为它正在等待资源（如 I/O）。资源可以是用于读取页面的 I/O，可以是网络上的通信，也可以是等待锁或闩锁的 WAIT。一旦它等待的任务完成，它就会被激活。例如，如果查询已经发布了一个 I/O 请求来读取一个完整表 tblStudents 的数据，那么这个任务将被挂起，直到 I/O 完成。一旦 I/O 完成（表 tblStudents 的数据在内存中可用），查询将移动到 RUNNABLE 队列中。

RUNNABLE:

SPID 位于调度程序的可运行队列中，并等待在调度程序上运行的量子。这意味着请求分配了一个工作线程，但它们没有获得所需的 CPU 时间。

RUNNABLE 队列可以比作一个杂货店，其中有多个结账行。登记员是CPU。只有一位顾客结账，例如在任何一个给定的寄存器中“运行”。在结帐行中花费的时间代表 CPU 压力。因此，此 SPID 正在等待正在运行的客户（与登记员）离开，以便它可以开始运行。可以使用查询 SELECT wait_type,waiting_tasks_count,signal_wait_time_ms FROM sys.dm_os_wait_stats ORDER BY signal_wait_time_ms DESC 找出等待线程发出信号的时间与其开始运行的时间之间的差异。这个差异是在 RUNNABLE 队列中花费的时间。可以安全地忽略列表顶部的一些等待。

PENDING:

会话正在等待工作线程变为可用。这意味着请求已准备好运行，但在 CPU 中没有可用于执行请求的工作线程。这并不意味着必须增加“最大工作线程”，但必须检查当前正在执行的线程在做什么操作以及为什么它们没有让出线程资源。我已经看到很多状态为 PENDING 的 SPID 的问题最终是“Non-yielding Scheduler”和“Scheduler deadlock”导致。

BACKGROUND:

会话正在运行后台任务，例如死锁检测。

SPINLOOP：

会话中的任务正在等待旋转锁变为可用。

SLEEPING:

没有做任何工作，SQL Server 正在重置会话。