查詢提示一直是個很有爭議的東西，因為他影響了sql server 自己選擇執行計划。很多人在問是否應該使用查詢提示的時候一般會被告知慎用或不要使用...但是個人認為善用提示在不修改語句的條件下，是常用手段。另外如果你是一個公司的dba 並且你對你所維護的數據庫了如指掌，對業務也有相當深刻的了解那么查詢提示也是你的一把利器。
但是，你所應用的提示是在現在的場景中基於現有的環境下，相對是一個好的方式，不能確保你所給予的提示永久有效，並且隨着時間推移，數據量的變更，你所加的提示可能成為噩夢。所以沒有充分的把握不要輕易使用提示。
下面說一說option (querytraceon 8649) 開啟強制並行，個人認為這個提示真心是個好東西（2005不支持），sql優化器經常會讓一個開銷較大的語句使用串行（稍后發文），這個時候當你加上option (querytraceon 8649) 會嚇你一跳 30秒變2秒？
下面作個例子說明一下：
串行計划
並行計划
時間縮短了將近一半（本機配置可憐...在一台好的服務器效果會更明顯）
我這可憐的配置
資源使用情況就不貼圖了，具體的並行執行原理請參見大神 指尖流淌的博客
http://www.cnblogs.com/zhijianliutang/p/4149850.html
我們繼續...這相當於消耗更多的資源來換取時間，但相對與要求反應更快的今天來說無疑是必要的選擇。
那么為什么SQL優化器生成一個串行計划，而不是“明顯更好的”並行計划，總有一個原因。配置設置被設置為一個最大程度的並行（前面的maxdop 1），或者只有一個邏輯處理器可用的SQL服務器，或並行抑制操作，基數估計錯誤，成本核算模型的局限性。
拋開其他因素我們來說一下因為語句寫法而造成的優化器不能選擇並行計划，大致一下幾點：
- 修改表變量操作（查詢是可以的）
- 使用標量函數 （這個是最常見查詢不能開啟並行的原因）
- CLR執行數據訪問的標量函數。
- 隨機的內在功能，如：object_name，encyptbycert等。
- 使用系統表，如：sys.tables。
還有一些功能是不能並行完成的，舉幾個常用情況如：
- top
- row_number
- 多語句表值函數。
- 遞歸CTE
提到並行就一定要提一下maxdop了，調整好這個參數也是很必要的，不一定是越大越好喲~ 等待類型CXPACKET很大程度上是因為過度並行導致的等待。