進程的狀態轉換 在說明SOS_SCHEDULER_YIELD等待之前，先簡要介紹一下進程的狀態（迷迷糊糊記得操作系統原理課上講過，三態五態轉換的，比下麵這個圖要複雜，大部分都還給老師了）。 如下圖，分別是：運行態，阻塞態，就緒態。各個狀態之間的轉換關係及粗略原因如下： 運行態-->阻塞態，原因：等待 ...
進程的狀態轉換
在說明SOS_SCHEDULER_YIELD等待之前，先簡要介紹一下進程的狀態（迷迷糊糊記得操作系統原理課上講過，三態五態轉換的，比下麵這個圖要複雜，大部分都還給老師了）。
如下圖，分別是：運行態，阻塞態，就緒態。各個狀態之間的轉換關係及粗略原因如下：
運行態-->阻塞態，原因：等待某種資源的完成，比如IO等。
阻塞態-->就緒態，原因：鎖請求的資源已完成，加入獲取CPU隊列中（going directly to the bottom of the Runnable Queue for the scheduler）。
運行態-->就緒態，原因：用完了一個CPU的時間片周期（當前線程仍未完成，需要CPU資源），那麼就等待進入下一個時間片周期。
（因為一個線程不會永久性占用CPU，CPU資源而是各個線程輪詢占用的一個過程）
SOS_SCHEDULER_YIELD類型等待
SQL Server中的調度機制也類似於進程的三態模型，運行，阻塞，就緒。
關於SOS_SCHEDULER_YIELD的問題之一是SOS_SCHEDULER_YIELD這種等待類型並非一種真正的等待，
當此種等待類型發生的時候，原因是線程耗盡了它的4ms的（時間片）輪詢周期，並且自動地讓出（voluntary yields）CPU資源,
直接被調度器排列在可執行新線程隊列的末尾，繞過等待信息列表，
此時的線程由執行態轉換為就緒態，雖然此等待記錄為SOS_SCHEDULER_YIELD等待，並不是因為真正的資源等待所導致的的。
而是CPU輪詢周期完成之後，當前線程任務仍沒有完成，需要等待輪詢下一個周期來獲取CPU資源執行導致的。
也就是說當然線程的執行一直在就緒和執行態之間轉換，從中可以推斷出當前線程是一個較為耗費CPU的操作。
不少參考資料上都是是掃描（ large scans happening ），如下
You want to investigate these waits if they’re a prevalent wait on your server,
as they could be an indicator of large scans happening (of data that’s already in memory)
where you’d really rather have small index seeks.
不過本人覺得這是全表或者索引掃描是僅僅存在的原因之一
其他有可能的原因，比如Hash Join，大結果集的Sort，Distinct等等，都是比較耗費CPU的。
另外就是，如果CPU確實比較忙，比如操作系統上的進程很多，CPU使用率很高
一個線程從就緒態到運行態需要等待的時間也會變長，因為等待占用CPU時間片的線程比較多。
總之，要明白的是，產生SOS_SCHEDULER_YIELD等待是因為當前線程需要耗費大量的CPU資源，
而CPU的調用機制是分時間片輪詢供各個線程使用的，當前線程在CPU周期結束的時候，仍舊沒有完成運算任務
那麼就要等到下一個CPU周期去獲取CPU資源，SOS_SCHEDULER_YIELD等待因此產生。
總結
SOS_SCHEDULER_YIELD類型等待並非真正意義上的等待資源，
而是CPU的一種調度機制導致較為耗費CPU資源的線程在執行過程中輪詢獲取CPU資源的一種現象。
有可能是線程運行的SQL語句本身性能較低，比如全面掃描之類的，或者是SQL語句本身邏輯運算，產生了Hash Join，排序之類的
如果發現有非常嚴重的SOS_SCHEDULER_YIELD類型等待，也應該慎重對待，比如從執行計劃等方面去分析是否是正常的
是否確實是數據高CPU使用類型的查詢，否則就要從SQL語句入手分析優化了。
參考
https://www.zhihu.com/question/53125711
https://www.sqlskills.com/blogs/paul/identifying-queries-with-sos_scheduler_yield-waits/
