通過上篇文章給大家介紹了SqlServer應用之sys.dm_os_waiting_tasks 引發的疑問(上) ，說了一下sys.dm_exec_requests 和 sys.dm_os_waiting_tasks 在獲取并行等待的時候得不同結果，這一篇我們談論下我的第二個疑問：為什么一個并行計劃（4線程）卻一下出現了那么多等待，SQL的并行到底是怎么執行的！！！！

　　　　先貼以下上篇sys.dm_os_waiting_tasks 的結果圖：

 　　　　我們分析一下這個結果的task_address 可以看出去掉重復其實只有9個，也就是說一個并行（4線程，配置不同，情況也不同）會有9個task。 又是線程，又是task ,還有worker,schedulers 這些都是什么？ 這個有必要先說一下，因為這篇博客前我也是亂亂的。

 scheduler

對于每個邏輯CPU，SQLSERVER會有一個scheduler與之對應，在SQL層面上代表CPU對象，只有拿到scheduler所有權的任務worker才能在這個邏輯CPU上運行

所謂邏輯CPU，就是SQLSERVER從Windows層面上看到的CPU數目，如果是一個雙核的CPU,那么一個物理CPU在SQL看來就是兩個邏輯CPU。如果系統還使用了

超線程hyper-threaded ,那對SQLSERVER來講就是4個邏輯CPU

規則： 每個scheduler上的最大worker數目等于SQLSERVER的最大線程數除以scheduler的數目 ，在同一個時間點，只能有一個擁有scheduler的worker處于運行狀態，其他worker都必須處于等待狀態。這樣能降低每個邏輯CPU上的處于正在運行狀態的線程數目，降低context switch，提供可擴展性scheduler是SQLSERVER的一個邏輯概念，他不與物理CPU相綁定。也就是說，一個scheduler可以被Windows安排一會兒在這個CPU上，一會兒在那個CPU上。

 但是，如果在sp_configure里設置了CPU affinity mask，那么scheduler就會固定在某個特定的CPU上

worker

每個worker跟一個線程（或纖程fiber）相對應，是SQLSERVER任務的執行單位。SQLSERVER不直接調度線程/纖程，而是調度worker，使得SQLSERVER能夠控制

任務調度

規則： 每個worker會固定代表一個線程（或纖程），并且和一個scheduler相綁定。如果scheduler是固定在某個CPU上的（通過設置CPU affinity mask），那么worker也會固定在某個CPU上每個scheduler有worker的上限值，并且可以根據SQLSERVER工作負荷創建或釋放worker，每次worker都會去運行一個完整的任務（task）。在任務做完之前不會退出，除非這個任務主動進入等待狀態。

scheduler只在有新任務要運行，而當前沒有空閑的worker的情況下，才會創建新的worker。

某個worker空閑超過15分鐘，scheduler可能會刪除這個worker，以及其對應的線程。當SQLSERVER遇到內存壓力的時，也會大量刪除處于空閑狀態的worker，以節省multi-page的內存開銷各種CPU和SQLSERVER版本組合自動配置的最大工作線程數CPU數                 32位計算機                        64位計算機
=4                     256                                  512
8                          288                                  576
16                        352                                  704
32                        480                                  960

task

在worker上運行的最小任務單元。最簡單的task就是一個簡單batch。例如，客戶發過來下面的請求：

 SELECT @@SERVERNAME
 GO
 SELECT GETDATE()
 GO 

那么這兩個batch就分別是兩個task。SQLSERVER會先分配給第一個batch（select @@servername）一個worker，將結果返回給客戶端，再分配第二個batch

（select getdate()）一個worker。這兩個worker可能是不同的worker，甚至在不同的scheduler上只要一個task開始運行，他就不會從這個worker上被移出。例如，如果一個select語句被其他連接阻塞住，worker就不能繼續運行，只能進入等待狀態。但是這個select task 不會將這個worker釋放，讓他做其他任務。所以結果是這個worker所對應的線程會進入等待狀態

yielding

 SQLOS的任務調度算法的核心，就是所有在邏輯scheduler上運行的worker都是非搶占式的 （non-preemptive）。worker始終在scheduler上運行，直到他運行結束，或者主動將scheduler讓出給其他worker為止。這個“讓出”scheduler的動作，我們叫yieding每個scheduler都會有一個runnable列表，所有等待CPU運行的worker都會在這個列表里排隊，以先進先出的算法，等待SQL分配給他scheduler運行SQLSERVER定義了很多yieding的規則，約束一個task在scheduler運行的時間。如果task比較復雜,不能很快完成，會保證task在合適的時間點做yieding，不至于占用scheduler太多時間。

常見時間點：

1、當worker每次要去讀數據頁的時候，SQLSERVER會檢查這個worker已經在scheduler上運行了多久，如果已經超過4ms，就做yielding

2、每做64KB的結果集排序，就會做一次yielding

3、在做語句編譯compile的過程中（這個過程比較占CPU資源），經常會有yieding

4、如果客戶端不能及時把結果集取走，worker就會做yieding

5、一個batch里的每一句話做完，都會做一次yieding

正常來講，哪怕一個task要做很久，他使用的worker是會經常做yieding的，不會長時間占用CPU不放。如果在一個scheduler上同時有很多worker要運行，SQLSERVER通過worker自動yielding的方式調度并發運行。這個比Windows用上下文切換context switch更有效

　　　　另附一張手繪圖

　　　　另外推薦一篇 SQL SERVER SQLOS的任務調度 微軟亞太的官方博客

　　　　我們大概了解了一下SQL SERVER SQLOS的任務調度 我們回到我們的并行話題看一下這個并行執行的調度情況： 

　　　　一個并行處理分配給了9個task，同時也啟用了9個worker，由4個scheduler調度，每個scheduler分別由一個申請數據，另一個等待。那么申請數據的是可以理解的，等待的是干什么的呢？個人理解和當前的執行計劃有關，4個線程取得數據后要做匯總的操作SQL不會等待數據獲取以后再開啟線程接收，而是接收線程在獲取數據的時候等待。

　疑問得到解決了么？因為已經標記為中篇，可見還是有疑問呀！！！！我們繼續下一篇吧....