平行程度

SQL Server 會針對平行查詢執行或索引資料定義語言 (DDL) 作業的每一個執行個體，自動偵測最佳程度的平行處理原則。其作法是依據下列條件：

1. SQL Server 是否正在具有多個微處理器或 CPU 的電腦上執行，例如對稱微處理電腦 (SMP)。

   具有一個以上 CPU 的電腦，才能使用平行查詢。

2. 是否有足夠的執行緒可用。

   每一個查詢或索引作業都需要某個數目的執行緒來執行。執行平行計畫所需的執行緒會比執行序列計畫還多，而且所需的執行緒數目會隨著平行處理原則的程度增加。當無法滿足針對平行處理原則之特定程度的平行計畫執行緒需求時，Database Engine 會自動降低平行處理原則的程度，或是完全放棄指定工作負載內容中的平行計畫。接著會執行序列計畫 (一個執行緒)。

3. 已執行的查詢或索引作業類型。

   建立或重建索引，或是卸除叢集索引的索引作業，以及大量使用 CPU 循環的查詢，最適合使用平行計畫。例如，聯結大型資料表、大型彙總及排序大型結果集，皆適用於平行計畫。經常在交易處理應用程式中發現的簡單查詢，會尋找執行平行查詢時所需的其他協調作業，此平行查詢比潛在的效能提升更為重要。為區分能否從平行處理原則中獲益的查詢，Database Engine 會比較執行查詢或索引作業的預估成本與 cost threshold for parallelism 的值。雖然不建議這麼做，但使用者可以使用 sp_configure 來變更預設值 5。

4. 要處理的資料列數目是否足夠。

   如果查詢最佳化工具判定資料列數目太少，則它不會引進交換運算子來散發資料列。因此，運算子會循序執行。在序列計畫中執行運算子，可避免啟動、散發、協調成本超過執行平行運算子所獲得的利益時的案例。

5. 目前是否有可用的散發統計資料。

   如果無法使用平行處理原則的最高程度，則在放棄平行計畫前，會先考慮降低程度。

   例如，當您在檢視中建立叢集索引時，因為叢集索引尚未存在，所以無法評估散發統計資料。在此情況下，Database Engine 無法為索引作業提供平行處理原則的最高程度。然而，有些運算子 (如排序及掃描) 仍可從平行執行獲益。

執行時，Database Engine 會判定先前描述的目前系統工作負載及組態資訊是否允許平行執行。如果保證可以平行執行，則 Database Engine 會判定最佳的執行緒數目，並將平行計畫的執行分散到那些執行緒上。當查詢或索引作業開始在多個執行緒上執行，以進行平行執行時，則在完成作業之前，都會使用相同數目的執行緒。每次從程序快取擷取執行計畫時，Database Engine 都會重新檢查最佳的執行緒決策數目。例如，執行查詢可能會使用到序列計畫，稍後執行同一個查詢會導致平行計畫使用三個執行緒，而第三次執行查詢的結果則是平行計畫使用四個執行緒。

在平行查詢執行計畫中，會循序執行插入、更新及刪除運算子。然而，UPDATE 或 DELETE 陳述式的 WHERE 子句，或 INSERT 陳述式的 SELECT 部份，可能會以平行方式執行。真正的資料變更隨即會循序套用到資料庫。

靜態和索引鍵集衍生的資料指標可以利用平行執行計畫來擴展。但是，動態資料指標的行為僅能由序列執行來提供。而最佳化工具所產生的查詢序列執行計畫，一定是動態資料指標的一部份。