一.概念
SOS_SCHEDULER_YIELD等待類型是一個任務自願放棄當前的資源占用，讓給其他任務使用。 這個等待類型與CPU有直接關系，與內存與也有間接關系，與CPU有關系是因為在sql server里是通過任務調度SCHEDULER來關聯CPU。 通過SCHEDULER下的Worker線程來處理SQL任務。為什么跟內存有關系呢，是因為獲取的資源需要內存來承載。
Yelding的發生：是指SCHEDULER上運行的Worker都是非搶占式的, 在 SCHEDULER上Worker由於資源等待，讓出當前Worker給其它Worker就叫Yielding。 關於SCHEDULER_YIELD產生的原理查看 sqlserver 任務調度與CPU。SOS_SCHEDULER_YIELD 等待的情況可以了解到:
(1)CPU有壓力
(2) SQL Server CPU scheduler 使用得當處理就會效率高。
1.1 從實例級別來查看等待數
select wait_type, waiting_tasks_count, wait_time_ms , max_wait_time_ms, signal_wait_time_ms from sys.dm_os_wait_stats where wait_type like 'SOS_SCHEDULER_YIELD%' order by wait_type
查詢如下圖所示:
這個等待類型排名第二，從請求的次數來說有69367060次，也就是說該線程用完了4ms的時間片，主動放棄cpu。如果沒有大量的runnable隊列或者大量的signal wait，證明不一定是cpu問題。因為這兩個指標是cpu壓力的一個體現。需要檢查執行計划中是否存在大量掃描操作。
1.2 通過dmv scheaduler的描述查看cpu壓力
SELECT scheduler_id, current_tasks_count, runnable_tasks_count, work_queue_count, pending_disk_io_count FROM sys.dm_os_schedulers WHERE scheduler_id < 255
如下圖所示：
如果你注意到runnable_tasks_count計數有兩位數，持續很長時間（一段時間內），你就會知道CPU壓力。兩位數字通常被認為是一件壞事 無法應對當前負荷。另外可以通過性能監視器%Processor Time 來查看CPU的狀況。
1.3 通過案例實時查看sql語句級的資源等待
SELECT * FROM sys.dm_exec_requests WHERE wait_type LIKE 'SOS_SCHEDULER_YIELD%'
-- 或查找資源等待的
SELECT session_id ,status ,blocking_session_id
,wait_type ,wait_time ,wait_resource
,transaction_id
FROM sys.dm_exec_requests
WHERE status = N'suspended';
如下圖所示 運行sys.dm_exec_requests 表，由於字段多截取了三斷。會話202的sql 語句上一次 等待類型是SOS_SCHEDULER_YIELD。之所以會出現YIELD，是因為SCHEDULER下的Worker已經發起了task 命令，但由於資源等待 如鎖或者磁盤輸入/輸出等，Worker又是非搶占式，所以讓出了當前的Worker。
1.4 減少sos_scheduler_yield 等待
正如上面所討論的，這種等待類型與CPU壓力有關。增加更多CPU是簡單的解決方案，然而實現這個解決方案並不容易。當這個等待類型很高時，你可以考慮其他的事情。這里通過從緩存中找到與CPU相關的最昂貴的SQL語句。
--查詢編譯以來 cpu耗時總量最多的前50條(Total_woker_time) 第一種查詢
select
'total_worker_time(ms)'=(total_worker_time/1000),
q.[text], --DB_NAME(dbid),OBJECT_NAME(objectid),
execution_count,
'max_worker_time(ms)'=(max_worker_time/1000),
'last_worker_time(ms)'=(last_worker_time/1000),
'min_worker_time(ms)'=(min_worker_time/1000),
'max_elapsed_time(ms)'=(max_elapsed_time/1000),
'min_elapsed_time(ms)'=(min_elapsed_time/1000),
'last_elapsed_time(ms)'=(last_elapsed_time/1000),
total_physical_reads,
last_physical_reads,
min_physical_reads,
max_physical_reads,
total_logical_reads,
last_logical_reads,
max_logical_reads,
creation_time,
last_execution_time
from
(select top 50 qs.* from sys.dm_exec_query_stats qs order by qs.total_worker_time desc)
as highest_cpu_queries cross apply sys.dm_exec_sql_text(highest_cpu_queries.plan_handle) as q
order by highest_cpu_queries.total_worker_time DESC