聯接提示
可以在使用JOIN時要求最終執行計劃使用指定的JOIN方式，支持LOOP\HASH\MERGE其一。這個我幾乎工作中極少使用到。除非生產環境慢SQL的執行計劃不合理，例如採用NESTED JOIN，但是LOOP的主表節點數據行數非常多，那是執行計劃錯誤，通過更新統計數據STATISTICS都無法解決，那就是SQL SERVER優化器的鍋。才需要通過聯接提示的方式改變SQL去優化。這個時候可以通過MERGE JOIN或者HASH JOIN的方式來實現。主要是HASH JOIN，因爲如果是MERGE JOIN是要求數據排序，如果本身有索引我相信優化器早就使用了，出現了錯誤採用NESTED JOIN操作的情況一定是HASH JOIN優化效果大於MERGE JOIN的。當然在優化的時候，條件允許的情況下肯定是要對比下MERGE JOIN和HASH JOIN的實際執行計劃的資源消耗差異（IO、CPU和TIME）
查詢提示
SQL結尾添加OPTION來指定查詢提示，支持的查詢提示非常多。查詢提示和聯結提示的使用場景其實是一樣的，只是在下面集中場景需要考慮使用查詢提示，查詢提示在性能調優中的考慮優先級其實是非常低的，考慮到目前SQL SERVER優化器的可靠性已經非常高的，一般情況下是不需要人爲干預的。執行計劃的選擇是受到SQL語句的參數、參數表字段的數據分佈和表數據行數變化影響的，而查詢提示會生硬的要求SQL SERVER按照我們的想法去選擇執行計劃，可能當下效果達到的，但是在選擇查詢提示的時候也要考慮未來的表數據變化，不然當下的改變會造成未來某一提前的問題，未來出現問題以後負責調優的DBA就不清楚當初你爲什麼要怎麼做。
1、SQL語句性能突然下降非常多，經過統計數據更新、索引優化、語句重寫都得不到解決或者達不到滿意的效果
2、統計數據、索引和語句寫法不存在問題或者最優的情況下，查詢計劃優化器的執行計劃選擇並不能滿足對性能的要求（就是執行時間還是不滿意）
上面兩種情況作爲DBA可能纔是需要考慮查詢提示。
不過這個顯示中用的也不多。列舉幾個用到的過或者覺得可能有用的。
HASH GROUP
HASH JOIN也好，HASH GROUP也好，HASH都是我認爲可能還存在使用場景的。因爲從過往經驗看，優化器容易選擇錯誤（造成性能大幅下降）的還是排序或者循環，這個對資源消耗是最大的，那麼HASH對於查詢是有大表參與的情況下是相對比較友好的。
MAXDOP
這個也是比較有用的，如果語句比較複雜且存在大表或者聚合操作，可以制定並行線程數量，以防把CPU資源喫死。如果你的語句本身會消耗CPU且表多或者表數據量特別大，又不會對語句的時間有要求，或者執行語句的時段正好是查詢繁忙的時間，那就可以指定這個去避免出現CPU資源喫死。
MAXRECUISION
遞歸層數限制，反正出現遞歸死循環。
RECOMPILE
如果查詢參數字段的數據分佈極不均勻，可以考慮加上RECOMPILE
TABLE HINT(table,INDEX(索引名), FORCESEEK)
指定查詢使用某個表索引，FORCESEEK要求使用檢索而不是表掃描
表提示
WITH跟在JOIN的表後面，比較有用的幾個表提示
INDEX
指定索引，主要用於要求SQL SERVER使用索引查找，前提是你對參數字段的數據分佈均勻性很有信心。
FORCESEEK
強制要求執行計劃選擇所有查找不是掃描，通常是跟着INDEX提示一起指明
HOLDLOCK|NOLOCK|READPAST|ROWLOCK|TABLOCK|XLOCK
這幾個可能是和鎖有關的幾個提示可能會用到的。HOLDLOCK主要是用到存儲過程事務裏面，先對錶加鎖後一直到事務提交，SELECT查詢用到。NOLOCK再常見不過。像生產環境查詢表數據通常加NOLOCK避免造成堵塞影響生產上的查詢，另外一個就是ETL抽數據也是加NOLOCK。REAPAST的使用場景是對於超高併發下更新數據，跳過已經加了鎖的行而取下一行。這個就是電商的秒殺場景或者取號場景。ROWLOCK也是針對高併發更新數據場景，對行級別加鎖而避免SQL SERVER對錶級別加鎖。TABLOCK就是相反，加表鎖是當前事務會在多處對數據進行更新，避免更新完後後面有其他的併發事務更新了表的行（如果不加表鎖，前面的數據更新是採用頁鎖或者行鎖，但是這樣子會影響當前存儲過程事務在後面對表的二次更新的數據結果，就需要加表鎖。）。TABLOCK另外一個變體是TABLOCKX，這個是直接排他，就是其他連接連表數據都不能查詢，直接堵塞其他對錶的查詢請求。XLOCK是最高級別的鎖，直接排他，指定XLOCK要同時指定ROWLOCK, PAGLOCK 或 TABLOCK。
參考：