Degree of Parallelism（并行度） ??? 一個(gè)查詢使用并行來處理時(shí)，SQL Server為該查詢分配多個(gè)線程，每個(gè)線程使用一個(gè)CPU進(jìn)行操作。Degree of Parallelism就是SQL Server為并行查詢分配的線程數(shù)量，也表明這個(gè)并行查詢將使用多少個(gè)CPU進(jìn)行并行處理。 ??? Exchange Oprators（交換操作） ??? 查詢語句的執(zhí)行計(jì)劃中，通常是并行操作和串行操作結(jié)合在一起。并行操作要求將輸入數(shù)據(jù)流（data stream）切分成多個(gè)（即degree of parallelism）部分，分別分配給各個(gè)線程進(jìn)行并行處理。并行查詢包括幾個(gè)數(shù)據(jù)流的交換操作（exchange operator），用以管理并行計(jì)劃的執(zhí)行。 ??? Distribute Steams ??? 執(zhí)行計(jì)劃中顯示為Parallelism/Distribute Steams。通常情況下，如果在一個(gè)串行操作之后緊接著一個(gè)并行操作，則這個(gè)并行操作將從前一個(gè)串行操作接收一個(gè)input stream。Distribute Steams就是并行查詢中將單個(gè)input stream分發(fā)到多個(gè)output stream中的操作。 ??? 例如一個(gè)serial table scan產(chǎn)生一個(gè)4000記錄的output stream，假設(shè)在這個(gè)table scan之后是一個(gè)并行操作，則在這兩個(gè)操作之間必須需要一個(gè)Distribute Steams操作，向并行操作的各個(gè)線程分發(fā)input stream。如果degree of parallelism為4，SQL Server根據(jù)關(guān)鍵字段，將這個(gè)4000記錄的stream分發(fā)成4個(gè)大致相當(dāng)?shù)膕tream，分別作為4個(gè)線程的input。< /font> ??? Distribute Streams操作之后，每一條input stream中的記錄，將出現(xiàn)在某一個(gè)output stream中，記錄的內(nèi)容和格式不會(huì)發(fā)生任何變化。SQL Server自動(dòng)在output stream中保留input stream中各記錄的相對(duì)順序。 ??? 通常，將使用Hashing以確定每一條輸入記錄被分發(fā)到哪一個(gè)output stream中。 ??? Gather Streams ??? 執(zhí)行計(jì)劃中顯示為Parallelism/Gather Streams。在并行操作結(jié)束之后，輸出結(jié)果保留在多個(gè)stream中。Gather Streams將并行操作的多個(gè)output stream收集到單個(gè)stream中。 ??? Gather Streams對(duì)多個(gè)stream進(jìn)行合并過程中，記錄的內(nèi)容和格式不會(huì)發(fā)生任何變化。如果各個(gè)input stream都是排序的，則Gather Streams的output stream也是排序的。 ??? Redistribute Streams/Repartition Streams ??? 執(zhí)行計(jì)劃中顯示為Parallelism/Repartition Streams。在一系列的并行操作中，在某個(gè)并行操作之后，可能需要對(duì)各個(gè)stream進(jìn)行重新組合，才能夠進(jìn)入下一個(gè)并行操作。< /font> ??? 例如Merge Join、Hash Join，都需要兩個(gè)input。這些操作的并行計(jì)劃中，每個(gè)并行的線程都應(yīng)當(dāng)擁有兩個(gè)獨(dú)立的input，各自執(zhí)行Merge Join、Hash Join操作，在并行Merge/Hash Join之后，使用Gather Streams操作，就得到完整的Merge/Hash Join的結(jié)果。如果在Merge/Hash Join前是一系列的并行計(jì)劃，則在進(jìn)入Merge/Hash Join時(shí)，各個(gè)并行線程擁有的stream可能不滿足"獨(dú)立的input"這個(gè)條件，此時(shí)就需要對(duì)進(jìn)入Merge/Hash Join的各個(gè)stream進(jìn)行重組，以使并行的各個(gè)線程獨(dú)立的完成Merge/Hash Join中的一部分。 ??? 每一條input stream中的記錄，在Repartition Streams操作之后將出現(xiàn)在其中一個(gè)output stream中，記錄的內(nèi)容和格式不會(huì)發(fā)生任何變化。如果各個(gè)input stream都是排序的，則Repartition Streams的各個(gè)output stream也是排序的。 ? ??? 示例< /div> ??? 示例中要使用到2個(gè)table： ??? TblBuyerItem( ??????? UserID NVARCHAR(40) NOT NULL, ??????? OrgID NVARCHAR(40) NOT NULL, ??????? ItemID NVARCHAR(40) NOT NULL) ??? 這個(gè)表的Clustered Index：OrgID,ItemID，記錄數(shù)為150萬。 ??? #alert_asn_shipoverdue( ??????? ORG NVARCHAR(40) NOT NULL, ??????? ITEM NVARCHAR(40) NOT NULL, ??????? VENDOR NVARCHAR(40) NOT NULL) ????這是個(gè)臨時(shí)表，沒有PK，沒有任何index，記錄數(shù)150。 執(zhí)行的SQL如下（沒有使用到TblBuyerItem的Clustered Index）： ??? SELECT a.UserID
??? FROM TblBuyerItem a
??? INNER JOIN #alert_asn_shipoverdue b?ON b.ORG=a.OrgID AND b.ITEM=a.ItemID
??? OPTION(MERGE JOIN) ??? 執(zhí)行計(jì)劃如下圖（裁減掉了個(gè)別步驟，點(diǎn)擊可以放大查看）：
??? 執(zhí)行計(jì)劃中，圖標(biāo)右下腳有個(gè)黃色小圓圈，里面有三個(gè)并行小箭頭，則表明這個(gè)操作是并行執(zhí)行的。 ??? 并行處理中的stream數(shù)據(jù)流如下圖所示： ???
? ??? 上圖示例degree of parallelism為3時(shí)的執(zhí)行情況。執(zhí)行過程介紹如下： ??? 先在#alert_asn_shipoverdue上執(zhí)行table scan，然后根據(jù)key column ORG、ITEM的值，為并行的Merge Join操作將#alert_asn_shipoverdue的數(shù)據(jù)分發(fā)到三個(gè)stream中，假設(shè)編號(hào)分別為B1、B2、B3。三個(gè)線程各自對(duì)所獲得的stream創(chuàng)建bitmap，然后進(jìn)行排序。 ??? 接下來，三個(gè)線程并行的在TblBuyerItem上執(zhí)行Clustered Index Scan。操作完成后每個(gè)線程獲得一個(gè)output stream，假設(shè)編號(hào)分別為A1'、A2'、A3'。現(xiàn)在A1'、A2'、A3'還不能與B1 、B2、B3匹配成A1'-B1、A2'-B2、A3'-B3，獨(dú)立的進(jìn)行Merge Join操作，因此根據(jù)key column OrgID、ItemID的 值，對(duì)A1'、A2'、A3'執(zhí)行Repartition Streams操作，為接下來的Merge Join重組A1'、A2'、A3'，并且使用bitmap過濾記錄。假設(shè)重組后的stream分別編號(hào)為A1、A2、A3，此時(shí)，三個(gè)線程分別使用A1 -B1、A2-B2、A3-B3作為輸入，執(zhí)行Merge Join操作。在Merge Join操作前，兩個(gè)input都必須是經(jīng)過排序的，因此每一個(gè)stream在進(jìn)入Merge Join操作前都有一個(gè)Sort操作。 ??? 最后，Gather Streams操作從三個(gè)線程的output stream中收集合并記錄集，得到完整的Merge Join結(jié)果記錄集。 ? ??? Parallel query并不能節(jié)約內(nèi)存、CPU的資源開銷，因?yàn)閷tream進(jìn)行Distribute、Repartition、Gather都需要消耗更多的資源。但是Parallel query也許可以節(jié)約query的執(zhí)行時(shí)間。 ??? ??? Bitmap（位圖） ??? 在上面的示例中，可以看到Bitmap/Bitmap Create的操作。 ??? 在MANY-TO-MANY的Join中，兩個(gè)表可能存在大量不匹配的記錄。在上面的示例中，#alert_asn_shipoverdue的記錄只有150，而TblBuyerItem的記錄是1,500,000，如果直接對(duì)兩個(gè)表進(jìn)行 Merge Join，就必須為TblBuyerItem的1,500,000記錄進(jìn)行排序，這是一個(gè)成本非常高的操作。而在1,500,000記錄中，只有少量記錄符合匹配條件。Bitmap操作在Join操作前，快速的對(duì)數(shù)據(jù)進(jìn)行一次初步的過濾，減少Join操作的開銷。 ??? Bitmap in Merge Join ??? 仍以上面的示例來說明，在Parallelism/Distribute Streams操作之后，每個(gè)線程得到一個(gè)input stream，接下來各個(gè)線程為自己的stream創(chuàng)建bitmap。我們假設(shè)分配給線程1的stream編號(hào)為B1。Bitmap創(chuàng)建完成后，包含一系 列0、1的值，為1的位代表對(duì)應(yīng)于這一位，該stream中存在相應(yīng)的記錄；為0的位代表對(duì)應(yīng)于這一位，該stream中不存在相應(yīng)的記錄。在 Parallelism/Repartition Streams操作時(shí)，從input stream中循環(huán)取出每條記錄，先確定該記錄應(yīng)當(dāng)進(jìn)入哪一個(gè)output stream中。我們假設(shè)某一條記錄被確定應(yīng)當(dāng)放入編號(hào)為A1的output stream，這個(gè)output stream A1將與stream B1匹配，被分配給線程1，作為線程1 Merge Join的兩個(gè)輸入。接下來SQL Server使用這條記錄，查詢與output stream A1對(duì)應(yīng)的stream B1的bitmap。如果相應(yīng)的位值為0，則說明這條記錄在B1中不可能存在匹配的記錄，因此這條記錄被忽略掉，不會(huì)放入output stream A1中；如果相應(yīng)的位值為1，則說明這條記錄在B1中可能存在匹配的記錄，該記錄被放入output stream A1，繼續(xù)在后續(xù)的Merge Join中進(jìn)行精確的匹配。 ??? 關(guān)于bitmap具體如何創(chuàng)建還不清楚，猜想大致應(yīng)當(dāng)是如下的一個(gè)過程：使用hash算法進(jìn)行操作，在查詢優(yōu)化期間基于#alert_asn_shipoverdue 的Join字段ORG、ITEM可能出現(xiàn)的唯一值數(shù)量而確定bitmap的大小。這個(gè)過程和Hash Join中確定hash table buckes數(shù)量（和大小）有點(diǎn)類似。執(zhí)行期間，先使用這個(gè)bitmap大小的值創(chuàng)建bitmap，初始化各個(gè)位均為0。然后為#alert_asn_shipoverdue循環(huán)，對(duì)每一個(gè)ORG、ITEM的組合值進(jìn)行hash，得到的hash value對(duì)應(yīng)于bitmap中的某一個(gè)位，將這個(gè)位設(shè)為1。 ??? 基于上面bitmap的創(chuàng)建過程，在Parallelism/Repartition Streams操作時(shí)，某一條記錄被確定進(jìn)入哪一個(gè)output stream之后，即可以找到相對(duì)應(yīng)stream的bitmap。對(duì)這條記錄OrgID、ItemID的值，使用在bitmap創(chuàng)建時(shí)相同的hash算法，用得到的hash value查找對(duì)應(yīng)的位。 ? ??? 下面看一下示例中bitmap的使用帶來的效果（點(diǎn)擊可以放大查看）： ?
??? 在對(duì)TblBuyerItem進(jìn) 行scan時(shí)，Row Count為1,543,050。在Repartition Streams操作中，WHERE:(PROBE([Bitmap1002])=TRUE)表明對(duì)bitmap的使用，Row Count 3,138。另外，從上圖中可以看出，示例的SQL實(shí)際執(zhí)行時(shí)使用了8 CPU。 ??? 附加說明：在上面的示例中，#alert_asn_shipoverdue很小，并且bitmap的create 和probe過程，其實(shí)已經(jīng)和Hash Join差不多。事實(shí)上，讓SQL Server自動(dòng)選擇Join Type時(shí)，使用的是Hash Join（參考[Join Type實(shí)例說明]，使用的是同樣的示例）。使用Hash Join時(shí)用的是serial方式，耗時(shí)4秒多；上面的示例耗時(shí)2秒；上面示例不使用并行處理（MAXDOP 1）時(shí)，耗時(shí)1分30多秒。 ? ??? Merge Join中，在outer input的分支進(jìn)入Merge Join前，必須有一個(gè)Sort操作，SQL Server才能使用bitmap。這是因?yàn)檫@個(gè)Sort操作使得整個(gè)outer input的分支處理完畢之后，才開始inner input分支的執(zhí)行，最后再進(jìn)入Merge Join操作。這樣inner input分支執(zhí)行時(shí)，才能使用在outer input分支上創(chuàng)建的bitmap。如果沒有這個(gè)Sort操作，SQL Server會(huì)同時(shí)開始處理outer input分支和inner input分支，這樣是無法使用bitmap的。 ??? 我們可以在上面的示例上做一個(gè)驗(yàn)證。假如在#alert_asn_shipoverdue有一個(gè)clustered index(ORG,ITEM)，那示例中的SQL語句執(zhí)行時(shí)會(huì)是什么狀況？在(ORG,ITEM)上創(chuàng)建clustered index后，執(zhí)行計(jì)劃變成下圖所示（點(diǎn)擊可以放大查看）：
??? 對(duì)#alert_asn_shipoverdue的Table Scan變成了Clustered Index Scan，得到的stream是按照ORG、ITEM排序的。 ??????
??? 現(xiàn)在，在Parallelism/Distribute Streams操作前的stream是按ORG、ITEM排序的，因此Distribute Streams的各個(gè)output stream也是按照ORG、ITEM排序的，因此這個(gè)outer input分支在Merge Join前不再需要Sort操作，這樣的話就無法使用bitmap了。 ??? 從執(zhí)行計(jì)劃圖中可以看到，inner input的分支，在TblBuyerItem的Table Scan之后，箭頭的大小一直到Merge Join操作沒有變化，說明在這個(gè)分支上一系列的操作中，記錄數(shù)基本上沒有什么變化。下圖是TblBuyerItem的Table Scan和Parallelism/Repartition Streams的詳細(xì)信息（點(diǎn)擊可以放大查看）： ?
??? 在這個(gè)驗(yàn)證中，沒有使用bitmap的平均執(zhí)行時(shí)間是1分10秒。 ? ??? Bitmap in Hash Join ??? Hash Join中的bitmap，總體上來講跟Merge Join中的處理是一樣的。在build input（outer input）上構(gòu)造hash table時(shí)是并行處理的，構(gòu)造hash table的同時(shí)也為每個(gè)build input的stream創(chuàng)建bitmap。當(dāng)整個(gè)build階段完成后，再開始probe階段，因此在probe階段執(zhí)行時(shí)已經(jīng)可以使用bitmap， 接下來的操作就跟Merge Join中Probe Bitmap操作完全一樣。 ? ??? SQL Server只在Parallel Query中使用bitmap，估計(jì)是Probe Bitmap結(jié)合Parallel Query中的Repartition操作，可節(jié)約的成本比較明顯。在Serial Query中，額外的去Probe Bitmap，可能對(duì)查詢的執(zhí)行并不能帶來明顯的改善。 ? ??? OK,It's over now. 下面回顧一下示例的語句在各種情況下的執(zhí)行效果： ???????
? ??? 參考： ??? MSDN - Parallel Query Processing ??? MSDN - Bitmaps in Microsoft SQL Server 2000 ??? MSDN - Logical and Physical Operators

轉(zhuǎn)載于:https://www.cnblogs.com/wayne-ivan/archive/2007/06/27/797062.html

總結(jié)

以上是生活随笔為你收集整理的Parallel Query Bitmap的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。