推薦：談SQL將挑戰操作系統安全
對于個人用戶來說，除了病毒和木馬，網頁中的隱形代碼也開始嚴重地威脅著我們的安全，但大多數人卻缺乏自我保護意識，對隱形代碼的危害認識不夠，甚至在自己不知情的情況下被別人竊取了重要資料。因為隱形代碼具有比較大的隱蔽性，到目前為止，還沒有什么病

并行查詢其優勢就是可以通過多個線程來處理查詢作業，從而提高查詢的效率。SQL Server數據庫為具有多個CPU的數據庫服務器提供并行查詢的功能，以優化查詢作業的性能。也就是說，只要數據庫服務器有多個CPU，則數據庫系統就可以使用多個操作系統進程并行執行查詢操作，來加速完成查詢作業。

一、并行查詢三步走

并行查詢作業在數據庫中，主要經過三個步驟。

首先，數據庫會判斷是否需要進行并行查詢。在數據庫中有一個查詢優化器，會對SQL語句進行優化，然后數據庫才會去執行查詢語句。而這個查詢器在對SQL語句進行查詢優化時，其中一個動作就是判斷是否需要對SQL語句進行查詢優化。也就是說，并不是所有的SQL查詢語句都可以從并行查詢中獲取收益。如果查詢優化器認為查詢語句可以從并行查詢中獲取收益的話，則就會將交換運算符插入到查詢執行計劃中，為并行查詢做準備。故哪些語句需要采用并行查詢，哪些不需要，這不用數據庫管理員關心。數據庫查詢優化器會幫管理員作出這個決定。數據庫管理員需要清楚的是，在哪些情況下，數據庫SQL優化器會認為不宜采用并行查詢。通常情況下，只要滿足以下條件的任何一個，則就不會執行并行查詢。一是對于特定的查詢，查詢優化器認為串行查詢執行計劃要快于任何可能的并行執行計劃;二是查詢的串行執行成本并不高，不需要進行并行查詢;三是查詢中包含無法并行運行的標量運算符或者關系運算符。若從數據庫管理員的角度講，第三個條件對我們具有最大的影響。當數據庫預計未來可能利用并行查詢來提高數據庫性能時，則在數據庫設計時，就需要注意避免使用那些無法在并行查詢功能中使用的運算符。因為某些關系運算符或者邏輯運算符可能會要求查詢計劃一定要在串行模式中進行，或者部分需要在串行模式下進行。如此的話，查詢優化器就不會利用并行查詢功能來提高查詢語句的性能。這是數據庫管理員在數據庫設計時必須要考慮到的一個細節問題。

其次，確定并行的進程數。當查詢優化器在查詢語句中插入交叉運算符之后，數據庫就會執行并行查詢。并行查詢在執行計劃時可以使用多個線程。此時，就又遇到了一個問題，數據庫會把這個查詢作業分成幾個進程操作呢?此時，數據庫管理員就需要知道上什么叫做并行度。其實。在處理并行查詢的時候，數據需要知道最大可使用的進程與實際使用的進程。而最大可使用的進程就叫做并行度。這個并行度的值是在服務器級別中進行設置，也可以通過系統存儲過程來進行修改。但是，最大可使用進程數不一定等于實際是用進程數。實際是用進程數是數據庫在查詢計劃執行時初始化的時候確定的。也就是說，這不用數據庫管理員去額外的設定。數據庫系統會自動根據計劃的復雜程度來確定合理的進程數目。當然其實際采用的進程數不能夠超過并行度，即最大可以使用的進程數。

最后執行查詢。當以上內容確定好之后，數據庫就會執行具體的查詢語句。在這一步中，需要注意一個問題。數據庫管理員還可以在查詢語句中指定MAXDOP查詢提示來修改這個進度值。也就是說，如果某個查詢作業數據庫管理員認為可能會耗時比較久，就可以為這個查詢作業設置比較大的進度值。當利用MAXDOP查詢提示設置這個并行進度值之后，它會覆蓋預先設置的默認值。從而實現針對單個查詢語句設置額外的進度值，以提高某些特殊查詢作業的性能。

二、并行查詢中需要注意的內容

注意點一：需要注意硬件方面的限制。

并行查詢是數據庫提高查詢性能的一個有力舉措。不過其往往受到比較大的約束。如上面提高的一些基于成本考慮之外，還有一些硬性的限制。如通常情況下，只有在數據庫服務器有多個微處理器(CPU )的情況下數據庫才會考慮執行并行查詢。也就是受，只有具有多個CPU的計算機才能夠使用并行查詢。這是一個硬性的限制條件。另外在查詢計劃執行過程中，數據庫還會判斷當時是否有足夠多的線程可以使用。每個查詢操作都要求一定的線程數才能夠執行;而且執行并行計劃比執行串行計劃需要更多的線程，所需要的線程數也會隨著并行度的提高而提高。如果在并行計劃執行的時候，當時數據庫服務器沒有足夠的線程讓并行計劃使用的話，數據庫引擎就會自動減少并行度，甚至會放棄并行查詢而改為串行計劃。所以說，數據庫是否能夠執行并行查詢，要受到其硬件的限制。為此，如果企業真的需要通過并行查詢來提高數據庫性能的話，則管理員就需要根據情況來調整硬件配置。

注意點二：不建議對所有查詢都使用并行查詢。

通常情況下，筆者認為最好只對大型表的連接查詢、大量數據的聚合操作、大型結果集的重復排序等等操作才應用并行查詢的功能。如果在這些操作上執行并行查詢的話，那么其改善數據庫性能的效果是非常明顯的。相反，如果對于簡單查詢執行并行查詢的話，可能執行并行查詢所需要的額外協調工作會大于其潛在的性能提升。所以，數據庫管理員在確定是否需要執行并行查詢功能的話，需要慎重。筆者的建議是，在數據庫服務器級別上，最好不要設置并行查詢。即把并行度設置為1或者一個比較小的值。然后對于一些特殊的查詢操作，利用MAXDOP查詢提示來設置最大的可使用進程數。如此的話，可能會更加的合理。如果有時候數據庫管理員不知道是否需要采用并行查詢功能的話，則可以通過數據庫自帶的統計功能進行判斷。為了區別并行查詢計劃到底有沒有從并行查詢中受益，數據庫引擎可以將執行查詢的估計開銷與并行查詢的開銷閥值進行比較。并行計劃只有對需時較長的查詢通常更加有益;因為其性能優勢將抵消初始化、同步和終止并行計劃所需的額外時間開銷。

注意點三：數據庫會根據查詢所涉及到的行數來判斷是否要并行查詢。

上面談到，最好對大型表的連接查詢、大量數據的聚合操作、大型結果集的重復排序等等操作才應用并行查詢的功能。因為只有如此，并行查詢帶來的收益才會超過其付出的代價。但是，并不是說連接查詢、聚合操作、排序等作業都適合采用并行查詢。當數據庫在考慮并行查詢計劃的時候，查詢優化器還會去確定所涉及到的行數。如果所涉及到的行數臺少，則將不會考慮執行并行查詢計劃。而會采用串行方式執行查詢語句。如此的話，可以避免因為啟動、分發、協調的開銷大大超過并行執行作業所帶來的收益。這本來是一個不錯的設計，但是也會給數據庫管理員帶來一定的麻煩。如現在數據庫管理員想要測試并行查詢到底可以在多大程度上影響查詢操作，就有點麻煩。因為其有數據量的限制。如果數據庫管理員需要進行這個測試，還不得不先在數據庫系統中導入足夠多的數據才行。這就限制了數據庫管理員的測試操作。不過話說回來，這個機制仍然是不錯的。因為數據庫管理員不用去考慮，當數據庫規模到多大的時候采用并行查詢。

注意點四：同一個操作在不同時候會采用不同的進程數。

上面說到過，并行查詢到第采用多少進程數除了跟操作的復雜程度相關外，還直接跟當時的服務器狀態相關，如是否有足夠的進程數等等。所以，在不同的時間，即使是相同的數據、相同的操作，其并行查詢所用的進程數也可能不同。其所需要的時間也就不同了。因為只有在并行查詢真正進行的時候，數據庫引擎才去收集當前系統的工作負荷，如進程數，和其他對一些配置信息，然后數據庫才確定最佳的并行進程數。從查詢開始，到這個查詢作業結束，將一直采用這個進程數。如果下次要繼續查詢，則數據庫引擎會繼續收集這些信息。此時，如果系統工作負荷有所改善，在數據庫可能會采用更多的進程數來執行這個查詢。從而查詢作業的性能會更加的高。相反，如果此時系統的負荷比前一次查詢要重了，則數據庫就可能會采用比較少的進程來處理這個作業。此時，第二次查詢的速度反而更慢了。所以，如果在數據庫服務器中同時部署了其他應用，則其他應用所占用系統資源的多少也會對并行執行產生難以估測的影響。

分享：解析SQL Server數據庫系統的編譯
你知道SQL Server這么龐大的企業級數據庫服務器產品是如何build出來的嗎? 這有些相關的數據： 每個build 的大小在300GB左右。 每個完整的build需要幾十臺高端的服務器運行2.5天。 每個完整的build由幾千個job、10000多個參數組成。 我們每天同時做20個左右的