SQLSERVER wait type之SOS_SCHEDULER_YIELD

如同在「SQL Server的等待分析」中所說，SQLSERVER會給一個處於RUNNING的thread一個限量的時間（4ms），如果這個thread在這個限量的時間內沒有執行完畢。若這個thread不需等待任何資源，則會將這個thread退回到Queue中（RUNNABLE）,即使目前沒有其它的thread在等侯CPU也是一樣。

SOS_SCHEDULER_YIELD嚴格的來說，它並不是一種等待，它只是線程在4ms時間內，無法完成工作而將CPU讓出來，以避免其它線程「餓死」的一種調度做法，所以它不會顯示在sys.dm_os_waiting_tasks中。它與一般的resource wait不同，它被稱為signal wait。如果系統中沒有其它的線程在runnable中，通常它的signal wait time的時間會很短，也就是很快又會回到running的狀態。

當一個thread超過限量時間，退回到runnable時，將被標示「SOS_SCHEDULER_YIELD」，直到它回到running狀態。這段時間將被紀錄為「訊號等待時間signal wait time」。

如果一個命令執行，耗用的CPU時間不超過4ms，那麼就不會有SOS_SCHEDULER_YIELD的出現，如果你看到許多次的SOS_SCHEDULER_YIELD，表示你的系統有許多命令耗用超過4ms的CPU。

當SOS_SCHEDULER_YIELD的等待次數很高，但總的等待時間卻不高，整體而言CPU並不忙碌。這通常是無害的，僅代表有較多的命令不能在4ms的限量時間完成。例如DBA關閉了平行處理（MAXDOP=1）,也有可能造成此現象。

當SOS_SCHEDULER_YIELD的等待次數很高，而且總的等待時間也很高。這非常可能代表了CPU有壓力。表示你的系統有許多CPU密集型的查詢，例如許多複雜的SQL statement，如table scan、複雜或不符合SARG的查詢..等，你可能需要針對特定的語法或物件進行優化。如果伴隨著高CXPACKET的出現，則需要去調整平行處理的配置。（詳見：SQLSERVER wait type之CXPACKET）

當SOS_SCHEDULER_YIELD的等待次數不高，但總的等待時間卻很高。這種情況表示你SQLSERVER所在的主機，作業系統的其它程式在搶佔CPU的資源。如果你在同一台主機上同時安裝了SQLSERVER和AP伺服器（或其它非DB相關的軟體），就有可能發生這種現象。或者在作業系統開啟了省電功能，也可能導致此種現象。