回答:
いいえ-待機統計は、サーバー自体に費やされた物理的な時間よりも長くなる可能性があります（多くの場合、そうなります）。
2つの別個のスレッドが同じリソースを待機するのに同じ秒を費やす状況を想像してください。1秒のクロック時間に対して2秒の待機時間があります。
各スレッドには独自の待機があります-メッセージは、その特定のリソースの20秒の待機時間がクロック時間の最後の5秒間に発生したことを示しています。
別の言い方をすれば、各コアが同時に複数のクエリを実行している場合があり、複数のコアが追加の待機を追加する場合があります。つまり、単位は実際には秒ではなくスレッド秒です。
例を通して作業することも役立つ場合があります。ワーカーの最も一般的な3つの状態を考えてみましょう。
RUNNING =ワーカーは現在、プリエンプティブまたはプリエンプティブに実行されています。
RUNNABLE =ワーカーはスケジューラで実行する準備ができています。
SUSPENDED =ワーカーは現在中断されており、イベントがシグナルを送信するのを待っています。
状態のワーカーはRUNNING待機時間を生成できます。たとえば、ワーカーがSQLOSではなくOSでコードを実行する必要がある場合、ワーカーはプリエンプティブまたは外部待機に入る可能性があります。その間、関連するCPUでコードを実行しますが、待機時間は引き続き生成されます。
状態のワーカーは、RUNNABLE待機時間を生成できます（私が知っている限りでは）。リソースが利用可能であることがワーカーに通知された場合、最後の待機に基づいて、シグナル待機時間が蓄積される場合があります。ワーカーが以前の4ミリ秒のクォンタムを使い果たした場合、SOS_SCHEDULER_YIELD待機時間が累積する可能性があります。
状態のワーカーはSUSPENDED待機時間を生成できます。ロックを待っているワーカーを考えてください。必要なロックリソースが利用可能であることが通知されるまで、待機時間を生成します。タスクに関連付けられていないものも含めて、中断されたワーカーの中には待機時間を生成しないものがあります。
デスクトップには4つの論理コアがあるため、デフォルトの最大ワーカー数は512です。ほぼ確実に非現実的ですが、このマシンでは、すべてのワーカーが一度に何かを待っていれば、理論的には1秒あたり512秒の待機時間を生成できます。コア/ワーカーの数が増えると、その数はさらに増える可能性があります。
SQL Serverに対してクエリを実行していない場合でも、1秒あたり1秒以上の待機を確認できます。私のマシンでは、次のクエリが9〜14行を生成するようです。
SELECT [state], last_wait_type, wait_started_ms_ticks
FROM sys.dm_os_workers
WHERE [state] IN ('SUSPENDED', 'RUNNABLE')
AND task_address IS NOT NULL
AND wait_started_ms_ticks <> 0
AND wait_started_ms_ticks >= start_quantum;サーバーを最後に再起動してからの合計待機時間のスナップショットを作成し、10秒待ってから新しい合計と比較できます。
DECLARE @start_wait_time_ms BIGINT;
SELECT @start_wait_time_ms = SUM(wait_time_ms)
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';
WAITFOR DELAY '00:00:10';
SELECT SUM(wait_time_ms) - @start_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';数学がうまくいくこともあります。前回実行したときのデルタは101339ミリ秒でした。言い換えれば、システムタスクだけで1秒あたり10秒以上待機していました。