查詢提示一直是個很有爭議的東西，因為他影響了sql server 自己選擇執行計畫。很多人在問是否應該使用查詢提示的時候一般會被告知慎用或不要使用...但是個人認為善用提示在不修改語句的條件下，是常用手段。另外如果你是乙個公司的dba 並且你對你所維護的資料庫瞭如指掌，對業務也有相當深刻的了解那麼查詢提示也是你的一把利器。
但是，你所應用的提示是在現在的場景中基於現有的環境下，相對是乙個好的方式，不能確保你所給予的提示永久有效，並且隨著時間推移，資料量的變更，你所加的提示可能成為噩夢。所以沒有充分的把握不要輕易使用提示。
下面說一說option (querytraceon 8649) 開啟強制並行，個人認為這個提示真心是個好東西（2005不支援），sql優化器經常會讓乙個開銷較大的語句使用序列（稍後發文），這個時候當你加上option (querytraceon 8649) 會嚇你一跳 30秒變2秒？
下面作個例子說明一下：
序列計畫
並行計畫
時間縮短了將近一半（本機配置可憐...在一台好的伺服器效果會更明顯）
我這可憐的配置
資源使用情況就不貼圖了，具體的並行執行原理請參見大神 指尖流淌的部落格
我們繼續...這相當於消耗更多的資源來換取時間，但相對與要求反應更快的今天來說無疑是必要的選擇。
那麼為什麼sql優化器生成乙個序列計畫，而不是「明顯更好的」並行計畫，總有乙個原因。配置設定被設定為乙個最大程度的並行（前面的maxdop 1），或者只有乙個邏輯處理器可用的sql伺服器，或並行抑制操作，基數估計錯誤，成本核算模型的侷限性。
拋開其他因素我們來說一下因為語句寫法而造成的優化器不能選擇並行計畫，大致一下幾點：
還有一些功能是不能並行完成的，舉幾個常用情況如：
提到並行就一定要提一下maxdop了，調整好這個引數也是很必要的，不一定是越大越好喲~ 等待型別cxpacket很大程度上是因為過度並行導致的等待。
SQL提示介紹 強制並行
查詢提示一直是個很有爭議的東西，因為他影響了sql server 自己選擇執行計畫。很多人在問是否應該使用查詢提示的時候一般會被告知慎用或不要使用.但是個人認為善用提示在不修改語句的條件下，是常用手段。另外如果你是乙個公司的dba 並且你對你所維護的資料庫瞭如指掌，對業務也有相當深刻的了解那麼查詢提...
SQL提示介紹 強制並行
查詢提示一直是個很有爭議的東西，因為他影響了sql server 自己選擇執行計畫。很多人在問是否應該使用查詢提示的時候一般會被告知慎用或不要使用.但是個人認為善用提示在不修改語句的條件下，是常用手段。另外如果你是乙個公司的dba 並且你對你所維護的資料庫瞭如指掌，對業務也有相當深刻的了解那麼查詢提...
cp 強制覆蓋的提示
在linux下的使用複製命令cp，不讓出現 overwrite 檔案覆蓋 提示的方法。一般我們在使用cp命令時加上 f選項，希望不讓出現 overwrite 的提示 檔案覆蓋的提示 如 cp rf sourcefile targetdir 或 cp r f sourcefile targetdir ...