web-dev-qa-db-ja.com

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

私は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)

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

sql-servert-sqlhintsmicrosoft-dynamics
31
Matthew Verstraete

_FAST N_は、Nとして定義された行数をすばやく返す実行プランを生成するようにSQL Serverに指示します。

SQLサーバーにN行をできるだけ速く取得するように指示しているので、見積もりは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)を使用したEstと実際の行

enter image description here

option (fast 500)のないEstと実際の行

enter image description here

ユースケースは、アプリケーションがキャッシング（バックグラウンドで大量のデータをロード）し、ユーザーにデータのスライスをすばやく表示したい場合です。できるだけ。

もう1つの興味深い使用例は SSISランドがロブ・ファーリー が_FAST N_をデータ検索を高速化する触媒として使用することを説明しています。

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

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

26
Kin Shah

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

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

14
codedawg82

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

ヒントを使用すると、SQL Serverは、すべてのレコードを読み取る（および場合によってはソートする）必要がある実行プランではなく、たとえばネストされたループから抜け出すときに、結果の一種のストリーミングを可能にする実行プランを見つけようとします出力されます。

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

したがって、OPに答えるには、多くのヒントと同様に、本来のクエリの改善に役立つとは限りません（テスト...テスト、テスト、テスト！）。

3
Nelson 2.0