注意點二：不建議對所有查詢都使用并行查詢。
通常情況下，筆者認為最好只對大型表的連接查詢、大量數據的聚合操作、大型結果集的重復排序等等操作才應用并行查詢的功能。如果在這些操作上執行并行查詢的話，那么其改善數據庫性能的效果是非常明顯的。相反，如果對于簡單查詢執行并行查詢的話，可能執行并行查詢所需要的額外協調工作會大于其潛在的性能提升。所以，數據庫管理員在確定是否需要執行并行查詢功能的話，需要慎重。筆者的建議是，在數據庫服務器級別上，最好不要設置并行查詢。即把并行度設置為1或者一個比較小的值。然后對于一些特殊的查詢操作，利用MAXDOP查詢提示來設置最大的可使用進程數。如此的話，可能會更加的合理。如果有時候數據庫管理員不知道是否需要采用并行查詢功能的話，則可以通過數據庫自帶的統計功能進行判斷。為了區別并行查詢計劃到底有沒有從并行查詢中受益，數據庫引擎可以將執行查詢的估計開銷與并行查詢的開銷閥值進行比較。并行計劃只有對需時較長的查詢通常更加有益;因為其性能優勢將抵消初始化、同步和終止并行計劃所需的額外時間開銷。
注意點三：數據庫會根據查詢所涉及到的行數來判斷是否要并行查詢。
上面談到，最好對大型表的連接查詢、大量數據的聚合操作、大型結果集的重復排序等等操作才應用并行查詢的功能。因為只有如此，并行查詢帶來的收益才會超過其付出的代價。但是，并不是說連接查詢、聚合操作、排序等作業都適合采用并行查詢。當數據庫在考慮并行查詢計劃的時候，查詢優化器還會去確定所涉及到的行數。如果所涉及到的行數臺少，則將不會考慮執行并行查詢計劃。而會采用串行方式執行查詢語句。如此的話，可以避免因為啟動、分發、協調的開銷大大超過并行執行作業所帶來的收益。這本來是一個不錯的設計，但是也會給數據庫管理員帶來一定的麻煩。如現在數據庫管理員想要測試并行查詢到底可以在多大程度上影響查詢操作，就有點麻煩。因為其有數據量的限制。如果數據庫管理員需要進行這個測試，還不得不先在數據庫系統中導入足夠多的數據才行。這就限制了數據庫管理員的測試操作。不過話說回來，這個機制仍然是不錯的。因為數據庫管理員不用去考慮，當數據庫規模到多大的時候采用并行查詢。
注意點四：同一個操作在不同時候會采用不同的進程數。
上面說到過，并行查詢到第采用多少進程數除了跟操作的復雜程度相關外，還直接跟當時的服務器狀態相關，如是否有足夠的進程數等等。所以，在不同的時間，即使是相同的數據、相同的操作，其并行查詢所用的進程數也可能不同。其所需要的時間也就不同了。因為只有在并行查詢真正進行的時候，數據庫引擎才去收集當前系統的工作負荷，如進程數，和其他對一些配置信息，然后數據庫才確定最佳的并行進程數。從查詢開始，到這個查詢作業結束，將一直采用這個進程數。如果下次要繼續查詢，則數據庫引擎會繼續收集這些信息。此時，如果系統工作負荷有所改善，在數據庫可能會采用更多的進程數來執行這個查詢。從而查詢作業的性能會更加的高。相反，如果此時系統的負荷比前一次查詢要重了，則數據庫就可能會采用比較少的進程來處理這個作業。此時，第二次查詢的速度反而更慢了。所以，如果在數據庫服務器中同時部署了其他應用，則其他應用所占用系統資源的多少也會對并行執行產生難以估測的影響。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
