並行查詢其優勢就是可以通過多個線程來處理查詢作業從而提高查詢的效率SQL Server數據庫為具有多個CPU的數據庫服務器提供並行查詢的功能以優化查詢作業的性能也就是說只要數據庫服務器有多個CPU則數據庫系統就可以使用多個操作系統進程並行執行查詢操作來加速完成查詢作業
一並行查詢三步走
並行查詢作業在數據庫中主要經過三個步驟
首先數據庫會判斷是否需要進行並行查詢在數據庫中有一個查詢優化器會對SQL語句進行優化然後數據庫才會去執行查詢語句而這個查詢器在對SQL語句進行查詢優化時其中一個動作就是判斷是否需要對SQL語句進行查詢優化也就是說並不是所有的SQL查詢語句都可以從並行查詢中獲取收益如果查詢優化器認為查詢語句可以從並行查詢中獲取收益的話則就會將交換運算符插入到查詢執行計劃中為並行查詢做准備故哪些語句需要采用並行查詢哪些不需要這不用數據庫管理員關心數據庫查詢優化器會幫管理員作出這個決定數據庫管理員需要清楚的是在哪些情況下數據庫SQL優化器會認為不宜采用並行查詢通常情況下只要滿足以下條件的任何一個則就不會執行並行查詢一是對於特定的查詢查詢優化器認為串行查詢執行計劃要快於任何可能的並行執行計劃;二是查詢的串行執行成本並不高不需要進行並行查詢;三是查詢中包含無法並行運行的標量運算符或者關系運算符若從數據庫管理員的角度講第三個條件對我們具有最大的影響當數據庫預計未來可能利用並行查詢來提高數據庫性能時則在數據庫設計時就需要注意避免使用那些無法在並行查詢功能中使用的運算符因為某些關系運算符或者邏輯運算符可能會要求查詢計劃一定要在串行模式中進行或者部分需要在串行模式下進行如此的話查詢優化器就不會利用並行查詢功能來提高查詢語句的性能這是數據庫管理員在數據庫設計時必須要考慮到的一個細節問題
其次確定並行的進程數當查詢優化器在查詢語句中插入交叉運算符之後數據庫就會執行並行查詢並行查詢在執行計劃時可以使用多個線程此時就又遇到了一個問題數據庫會把這個查詢作業分成幾個進程操作呢?此時數據庫管理員就需要知道上什麼叫做並行度其實在處理並行查詢的時候數據需要知道最大可使用的進程與實際使用的進程而最大可使用的進程就叫做並行度這個並行度的值是在服務器級別中進行設置也可以通過系統存儲過程來進行修改但是最大可使用進程數不一定等於實際是用進程數實際是用進程數是數據庫在查詢計劃執行時初始化的時候確定的也就是說這不用數據庫管理員去額外的設定數據庫系統會自動根據計劃的復雜程度來確定合理的進程數目當然其實際采用的進程數不能夠超過並行度即最大可以使用的進程數
最後執行查詢當以上內容確定好之後數據庫就會執行具體的查詢語句在這一步中需要注意一個問題數據庫管理員還可以在查詢語句中指定MAXDOP查詢提示來修改這個進度值也就是說如果某個查詢作業數據庫管理員認為可能會耗時比較久就可以為這個查詢作業設置比較大的進度值當利用MAXDOP查詢提示設置這個並行進度值之後它會覆蓋預先設置的默認值從而實現針對單個查詢語句設置額外的進度值以提高某些特殊查詢作業的性能
二並行查詢中需要注意的內容
注意點一需要注意硬件方面的限制
並行查詢是數據庫提高查詢性能的一個有力舉措不過其往往受到比較大的約束如上面提高的一些基於成本考慮之外還有一些硬性的限制如通常情況下只有在數據庫服務器有多個微處理器(CPU )的情況下數據庫才會考慮執行並行查詢也就是受只有具有多個CPU的計算機才能夠使用並行查詢這是一個硬性的限制條件另外在查詢計劃執行過程中數據庫還會判斷當時是否有足夠多的線程可以使用每個查詢操作都要求一定的線程數才能夠執行;而且執行並行計劃比執行串行計劃需要更多的線程所需要的線程數也會隨著並行度的提高而提高如果在並行計劃執行的時候當時數據庫服務器沒有足夠的線程讓並行計劃使用的話數據庫引擎就會自動減少並行度甚至會放棄並行查詢而改為串行計劃所以說數據庫是否能夠執行並行查詢要受到其硬件的限制為此如果企業真的需要通過並行查詢來提高數據庫性能的話則管理員就需要根據情況來調整硬件配置
注意點二不建議對所有查詢都使用並行查詢
通常情況下筆者認為最好只對大型表的連接查詢大量數據的聚合操作大型結果集的重復排序等等操作才應用並行查詢的功能如果在這些操作上執行並行查詢的話那麼其改善數據庫性能的效果是非常明顯的相反如果對於簡單查詢執行並行查詢的話可能執行並行查詢所需要的額外協調工作會大於其潛在的性能提升所以數據庫管理員在確定是否需要執行並行查詢功能的話需要慎重筆者的建議是在數據庫服務器級別上最好不要設置並行查詢即把並行度設置為或者一個比較小的值然後對於一些特殊的查詢操作利用MAXDOP查詢提示來設置最大的可使用進程數如此的話可能會更加的合理如果有時候數據庫管理員不知道是否需要采用並行查詢功能的話則可以通過數據庫自帶的統計功能進行判斷為了區別並行查詢計劃到底有沒有從並行查詢中受益數據庫引擎可以將執行查詢的估計開銷與並行查詢的開銷閥值進行比較並行計劃只有對需時較長的查詢通常更加有益;因為其性能優勢將抵消初始化同步和終止並行計劃所需的額外時間開銷
注意點三數據庫會根據查詢所涉及到的行數來判斷是否要並行查詢
上面談到最好對大型表的連接查詢大量數據的聚合操作大型結果集的重復排序等等操作才應用並行查詢的功能因為只有如此並行查詢帶來的收益才會超過其付出的代價但是並不是說連接查詢聚合操作排序等作業都適合采用並行查詢當數據庫在考慮並行查詢計劃的時候查詢優化器還會去確定所涉及到的行數如果所涉及到的行數台少則將不會考慮執行並行查詢計劃而會采用串行方式執行查詢語句如此的話可以避免因為啟動分發協調的開銷大大超過並行執行作業所帶來的收益這本來是一個不錯的設計但是也會給數據庫管理員帶來一定的麻煩如現在數據庫管理員想要測試並行查詢到底可以在多大程度上影響查詢操作就有點麻煩因為其有數據量的限制如果數據庫管理員需要進行這個測試還不得不先在數據庫系統中導入足夠多的數據才行這就限制了數據庫管理員的測試操作不過話說回來這個機制仍然是不錯的因為數據庫管理員不用去考慮當數據庫規模到多大的時候采用並行查詢
注意點四同一個操作在不同時候會采用不同的進程數
上面說到過並行查詢到第采用多少進程數除了跟操作的復雜程度相關外還直接跟當時的服務器狀態相關如是否有足夠的進程數等等所以在不同的時間即使是相同的數據相同的操作其並行查詢所用的進程數也可能不同其所需要的時間也就不同了因為只有在並行查詢真正進行的時候數據庫引擎才去收集當前系統的工作負荷如進程數和其他對一些配置信息然後數據庫才確定最佳的並行進程數從查詢開始到這個查詢作業結束將一直采用這個進程數如果下次要繼續查詢則數據庫引擎會繼續收集這些信息此時如果系統工作負荷有所改善在數據庫可能會采用更多的進程數來執行這個查詢從而查詢作業的性能會更加的高相反如果此時系統的負荷比前一次查詢要重了則數據庫就可能會采用比較少的進程來處理這個作業此時第二次查詢的速度反而更慢了所以如果在數據庫服務器中同時部署了其他應用則其他應用所占用系統資源的多少也會對並行執行產生難以估測的影響
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22469.html
