SELECTステートメントのOPTION FASTは何をしますか？

29

ステートメントOPTION (FAST XXX)内でクエリヒントが何をするかを掘り下げましたが、SELECTまだ混乱しています。MSDNによると：

クエリが最初のnumber_rowsの高速取得のために最適化されることを指定します。これは非負の整数です。最初のnumber_rowsが返された後、クエリは実行を継続し、完全な結果セットを生成します。

私にとってそれはあまり意味がありませんが、基本的にクエリは最初のXXX行を本当に速く取得でき、残りは通常の速度で取得できますか？

これについて考えさせられたMicrosoft Dynamicsクエリは次のとおりです。

select pjproj.project,pjproj.project_desc,pjproj.customer,pjproj.cpnyid
from pjproj WITH (NOLOCK)
where project like  '%'
order by project OPTION(FAST 500)

誰でもこのクエリヒントが何をしているのかを正確に説明できますか？それはそれを使用しないよりも有利です？

— マシュー・ヴァーストラリート
ソース

24

AはFAST N迅速として定義された行数を返すと実行計画を生成するために、SQL Serverのを教えてくれますN。

可能な限り高速に行Nを取得するようにSQLサーバーに指示しているため、推定値は次のようになりますN。

たとえば、次のクエリを実行しますfast 500：

-- total rows : 19972
 SELECT [BusinessEntityID]
      ,[TotalPurchaseYTD]
      ,[DateFirstPurchase]
      ,[BirthDate]
      ,[MaritalStatus]
      ,[YearlyIncome]
      ,[Gender]
      ,[TotalChildren]
      ,[NumberChildrenAtHome]
      ,[Education]
      ,[Occupation]
      ,[HomeOwnerFlag]
      ,[NumberCarsOwned]
  FROM [AdventureWorks2012].[Sales].[vPersonDemographics]
  order by BusinessEntityID
  option (fast 500)

推定対実際の行 option (fast 500)

推定行対実際行 option (fast 500)

ユースケースは、アプリケーションが（バックグラウンドでのデータのロード大量）キャッシングを行うと、すぐに可能な限りユーザーにデータのスライスを見せたいしたときだろう。

もう1つの興味深いユースケースは、データ検索を高速化する触媒として使用することをロブファーリーが説明しFAST NているSSISの土地です。

このヒントを追加すると、クエリ全体に魔法の杖が振られ、数倍速く実行されるように感じられました。

Remus Rusanuの回答も参照してください。

— キンシャー
ソース

11

このクエリヒントOPTION（FAST n）を使用すると、オプティマイザーは、可能な限り高速でその量のレコードを返すことができる実行プランを選択します。通常、オプティマイザーは、完全な結果セットを効率的に返すことができるパスを決定しようとします。したがって、行のセットをすばやく戻すには、これを使用してそれらを取得することもできますが、ほとんどの場合、このヒントを使用すると、オプティマイザが実行するプランを使用するよりも完全な結果セットが遅くなりますそう。

ユースケースについて詳しく説明すると、2つのかなり大きなテーブルを結合する必要がある場合がありますが、そのうちの1つを使用して作業する必要があるデータセットはごくわずかです。この場合、追加のインデックス/オーバーヘッドを作成せずに、より大きなテーブルでFASTを使用すると、SQLがバックグラウンドで巨大なハッシュテーブルを作成する代わりに役立ちます。

— コード化された
ソース

2

数年前、Dynamics AXのパフォーマンスの問題を調査するときに、同じ質問に出会いました。Microsoftの説明に従って、ヒントによってトリガーされる別の実行計画を見ることができました。これは、ここで示された他の回答に対応しています。

ヒントを使用すると、SQL Serverは、すべてのレコードを読み取る（および潜在的に並べ替える）必要がある実行プランの代わりに、たとえばネストされたループから出てくる結果の並べ替えを許可する実行プランを見つけようとします出力されています。

私の場合の唯一の問題は、SQLサーバーがヒントを使用するときに結果を返すのに常に（数）分かかるのに対し、クエリはヒントなしでほんの数秒で結果（結果セット全体）を返すことです...まったく何もありません期待された。私はこのヒントを個人的に細心の注意を払って使用し、Dynamics環境のようなすべてのフォームで体系的にではありません（まあ、もうありません）。

だから、OPに答えるために：多くのヒントのように、それはそれがするはずであるようにクエリを改善することを必ずしも助けません（そう...テスト、テスト、テスト！）

— ネルソン2.0
ソース