クエリ ヒントのドキュメントを読んでいました: http://msdn.microsoft.com/en-us/library/ms181714(SQL.90).aspx
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を使用する場合、 OPTIONFASTxも使用するメリットはありません。クエリオプティマイザは、取得する行数に基づいてすでに決定を下しています。一意のインデックスから特定の値をクエリするなど、簡単なクエリについても同じことが言えます。
それ以外に、結果の数がxを下回る可能性が高いことがわかっている場合は、 OPTION FAST xが役立ちますが、クエリオプティマイザーは役立ちません。もちろん、クエリオプティマイザが結果の少ない複雑なクエリに対して不適切なパスを選択している場合は、統計を更新する必要があります。また、 xについて間違った推測をすると、クエリに時間がかかる可能性があります。ほとんどの場合、ヒントを提供する際のリスクがあります。
上記のステートメントはテストされていません。すべてのクエリが完全に実行されるまでに、それ以上ではないにしても、同じくらいの時間がかかる可能性があります。行が8行しかない場合、最初の10行を高速に取得することは素晴らしいことですが、理論的には、クエリは終了する前に完全に実行する必要があります。私が考えている利点は、実際には最初のxをより速く取得しようとしているのに、クエリの実行が異なるパスをたどり、合計レコード数が少なくなることを期待しているためです。これらの2つのタイプの最適化は一致していない可能性があります。
その特定のクエリについては、確かにそうではありません! 1 つの行のみを返します — の行ID = 444です。SQL Server は、その行を可能な限り効率的に選択します。
FAST 10さらなる結果を待ち続けていても、最初の 10 行をすぐに利用できる状況で使用される可能性があります。