在這一期的性能調優培訓里，我想詳細講解下SQL Server里的并行執行計劃（Parallel Execution Plans） 。執行一個有并行執行計劃的查詢，意味著SQL Server從執行計劃里進行必須的運算符需要使用多線程。首先我會介紹下并行執行計劃里最常用的運算符，然后我們來分析下SQL Server是如何決定是否要使用并行執行計劃。

對于并行執行計劃最常見的誤解就是多線程只用于整個執行計劃。這是錯誤的，因為SQL Server可以分配多個工作線程給所有可并行（parallelism-aware）運算符。這就意味者一個大型的并行計劃可以消耗大量的線程。SQL Server在并行計劃里區分2類運算符：可并行（parallelism-aware）運算符，和稱為交換運算符（Exchange Operators）：

• 很多傳統的運算符可以使用多線程來進行它們的工作，它們是可并行（parallelism-aware）運算符：索引掃描（Index Scan），索引查找（Index Seek），嵌套循環（Nested Loop），哈希連接（Hash Join），排序（Sort）等。
• 交換運算符（Exchange Operators）是在并行執行計劃里，用來分發和合并多線程之間的行。

SQL Server使用下列3個交換運算符：

• Distribute Streams: 在并行計劃中，從一個單線程里區域轉變為多線程區域（接收記錄的單個輸入流，并生成多個輸出流。）。
• Repartition Streams: 在線程間重新分配行（例如，當前一個運算符是并行哈希連接）（處理多個流并生成多個記錄流。）。
• Gather Streams:在并行計劃中，從多線程區域轉變為單線程區域（處理幾個輸入流并通過組合這幾個輸入流生成單個記錄輸出流。）。

當你閱讀并行執行計劃時，你總會看到2種運算符的結合。每個執行計劃必須生成一個單線程的結果，因此在并行執行計劃的結尾，你總能看到Gather Streams運算符。

查詢優化器是否生成一個并行執行計劃也取決于你使用的查詢結構是否會阻止并行計劃，例如：

• T-SQL 語句和SQL公共語言運行庫的自定義函數（SQLCLR UDFs）；
• 內建函數，像OBJECT_ID(), ERROR_NUMBER(), @@TRANCOUNT等；

在并行計劃里，也有很多查詢結構會強制串行區域（這部分操作會使用并行計劃）：

• 系統表掃描（System Table Scans）
• 序列函數（Sequence Functions）
• 向后掃描（Backward Scans）
• 遞歸查詢（Recursive Queries）
• 表值函數（TVFs）
• TOP

在你的并行計劃里，串行區域越少，你的查詢越快。當你下次寫你的查詢時，好好考慮這點。

每個執行計劃都會被SQL Server分配一個成本因素（Cost Factor） 。成本因素就是用來告訴SQL Server這個執行計劃有多貴的簡單數字。這個數字越大，執行計劃運行的關聯成本就越高。

SQL Server有一個稱為并行開銷閥值（cost threshold for parallelism）的配置選項，用來定義成本因素，在哪個點查詢優化會考慮使用并行計劃。默認這個配置選項是5，也就說查詢高于這個成本值，只要并行計劃可行，就會使用并行計劃。

當并行計劃被查詢優化器編譯好后，最大并行度（Max Degree of parallelism（MAXDOP））選項定義對執行計劃中的每個并行運算符可用線程數。我剛才提過，并行執行計劃里的每個運算符都可以用多線程運行，而不是整個執行計劃。當然在并行執行計劃里，線程可以被前一個運算符共享和重用。可以通過服務器屬性->高級->并行配置這些屬性：

默認最大并行度（MAXDOP）選項值是0，因此SQL Server會默認將并行查詢穿過所有分配給SQL Server的CPU內核。當你使用NUMA（Non Uniform Memory access）系統時，這個會導致性能問題。最佳實踐是限制MAXDOP選項值，在NUMA節點里的核心數（包括超線程的核心數）范圍內。這樣就可以保證SQL Server的并行計劃呆在NUMA節點內。

這一期的性能調優培訓里我講解了SQL Server里的并行執行計劃，你學到了在并行執行計劃里涉及到的各種運算符，還有在SQL Server里你如何配置并行度。如果你想對并行計劃有更深入的了解，可以看下…………（此次內容待完善）。

看完這篇文章，性能調優培訓的第3個月就已經結束了，在下一個月我會講解下SQL Server里的統計信息。請繼續關注！