我讀了查詢提示的文檔在： http://msdn.microsoft.com/en-us/library/ms181714(SQL.90).aspx我應該使用查詢提示快速number_rows/FASTFIRSTROW？
，並注意到這一點： FAST一個number_rows 指定查詢的第一個number_rows的快速檢索優化。這是一個非負整數。在返回第一個number_rows之後，查詢繼續執行並生成其完整結果集。
所以，當我在做類似的查詢：
Select Name from Students where ID = 444
我應該不屑於這樣的暗示？假設SQL Server 2005，我應該什麼時候？
- 編輯 -
也應該限制的結果，當一個麻煩：
Select top 10 * from Students OPTION (FAST 10)
當使用TOP X，沒有也使用OPTION FAST X的好處。查詢優化器已根據您檢索的行數做出決定。平凡的查詢也是如此，例如查詢唯一索引中的特定值。
除此之外，OPTION FAST X可以幫助時你知道結果的數量很可能低於X，但查詢優化器不會。當然，如果查詢優化器爲複雜查詢選擇較差的路徑而結果很少，則可能需要更新統計信息。如果您在x上猜錯了，則查詢可能會花費更長的時間 - 提示時幾乎總是有風險。
以上聲明尚未經過測試 - 可能全部查詢花費的時間與完全執行時間一樣長（如果不更長）。如果只有8行，獲得前10行非常好，但理論上查詢仍然需要在完成前完全執行。我在想的好處可能在那裏，因爲查詢執行採取不同的路徑預計減少總計記錄，實際上它實際上試圖獲得更快的第一個x記錄。這兩種優化可能不一致。
對於特定的查詢，當然不是！它只會返回一行 - 與ID = 444行。 SQL Server將盡可能有效地選擇該行。
FAST 10可能在您可以立即使用前10行的情況下使用，即使您繼續等待更多結果。
FAST提示僅適用於複雜查詢，其中有多個可供優化程序選擇的備選方案。對於像你的例子這樣的簡單查詢，它對任何事情都沒有幫助，查詢優化器將立即確定存在一個簡單的計劃（在ID索引中尋找，如果沒有覆蓋，則查找Name）以滿足查詢並執行該查詢。即使ID上沒有索引，該計劃仍然是微不足道的（可能是集羣掃描）。
爲了給出一個FAST有用的例子，考慮使用ORDER BY約束考慮A和B之間的連接。先評估聯合B並嵌套循環A尊重ORDER BY約束，這樣會產生快速結果（不需要SORT），但由於基數（B有許多匹配WHERE的記錄，而A很少），所以成本更高。另一方面，評估B第一個和嵌套循環A會產生一個查詢，該查詢的IO較少，因此整體速度較快，但結果必須先排序，並且SORT只能在之後開始，因此第一個結果會來得很晚。優化器通常會選擇第二個計劃，因爲整體效率更高。 FAST提示會導致優化器選擇第一個計劃，因爲它可以更快地生成結果。