次の方法で共有


クエリ ヒント (Transact-SQL)

更新 : 2007 年 9 月 15 日

指定のクエリ ヒントをクエリ全体をとおして使用する必要があることを指定します。クエリ ヒントはステートメント内のすべての演算子に作用します。メイン クエリで UNION を使用する場合、UNION 操作を含む最後のクエリだけに OPTION 句を指定できます。クエリ ヒントは OPTION 句の一部として指定します。複数のクエリ ヒントが原因でクエリ オプティマイザが有効なプランを生成できない場合は、エラー 8622 が発生します。

ms181714.note(ja-jp,SQL.90).gif重要 :
通常、SQL Server 2005 クエリ オプティマイザでは、クエリにとって最適な実行プランが選択されるため、<query_hint> を含むヒントは、経験を積んだ開発者やデータベース管理者が最後の手段としてのみ使用することをお勧めします。

適用対象

DELETE

INSERT

SELECT

UPDATE

トピック リンク アイコンTransact-SQL 構文表記規則

構文

<query_hint > ::= 
{ { HASH | ORDER } GROUP 
  | { CONCAT | HASH | MERGE } UNION 
  | { LOOP | MERGE | HASH } JOIN 
  | FAST number_rows 
  | FORCE ORDER 
  | MAXDOP number_of_processors 
  | OPTIMIZE FOR ( @variable_name = literal_constant [ , ...n ] ) 
  | PARAMETERIZATION { SIMPLE | FORCED }
  | RECOMPILE
  | ROBUST PLAN 
  | KEEP PLAN 
  | KEEPFIXED PLAN
  | EXPAND VIEWS 
  | MAXRECURSION number 
  | USE PLAN N'xml_plan'
} 

引数

  • {HASH | ORDER} GROUP
    クエリの GROUP BY 句、DISTINCT 句、または COMPUTE 句に記述されている集計でハッシュまたは順序付けを使用することを指定します。
  • { MERGE |HASH |CONCAT } UNION
    UNION セットをマージ、ハッシュ、または連結することによって、すべての UNION 操作を実行することを指定します。複数の UNION ヒントを指定した場合、クエリ オプティマイザは指定されたヒントの中から最も負荷の軽い方法を選択します。

    ms181714.note(ja-jp,SQL.90).gifメモ :
    FROM 句の中で、特定の結合テーブルのペアに対して <joint_hint> も指定した場合、OPTION 句に指定した <join_hint> よりもこれが優先されます。
  • { LOOP | MERGE | HASH } JOIN
    LOOP JOIN、MERGE JOIN、または HASH JOIN によって、すべての結合操作がクエリ全体で実行されることを指定します。結合ヒントを複数指定した場合は、可能なヒントの中から最も負荷の軽いストラテジがオプティマイザによって選択されます。

    同じクエリの中で、特定のテーブルのペアに対して結合ヒントが指定されている場合も、2 つのテーブルの結合ではこの結合ヒントが優先されますが、クエリ ヒントは引き続き有効です。このため、テーブルのペアの結合ヒントは、クエリ ヒント内で許可される結合方法の選択を制限できるだけです。詳細については、「ヒント (Transact-SQL)」を参照してください。

  • FAST number_rows
    最初の number_rows. を高速検索するためにクエリの最適化を行うことを指定します。これは、負以外の整数です。最初の number_rows を返した後、クエリは実行を続け、完全な結果セットを作成します。
  • FORCE ORDER
    クエリの構文に示されている結合順序が、クエリの最適化中、保持されることを指定します。

    ms181714.note(ja-jp,SQL.90).gifメモ :
    FORCE ORDER を使用しても、クエリ オプティマイザのロールの逆引き動作に影響はありません。詳細については、「ハッシュ結合について」を参照してください。

    クエリにビューが含まれている場合の SQL Server クエリ オプティマイザによる FORCE ORDER ヒントの設定については、「ビューの解決」を参照してください。

  • MAXDOP number
    このオプションを指定しているクエリに対して、sp_configuremax degree of parallelism 構成オプションを上書きします。MAXDOP クエリ ヒントは、sp_configure で構成された値を超えることがあります。MAXDOP クエリ ヒントを使用している場合は、max degree of parallelism 構成オプションで使用されるすべての意味ルールを適用できます。詳細については、「max degree of parallelism オプション」を参照してください。
  • @variable_name
    クエリで使用されるローカル変数の名前です。このローカル変数に OPTIMIZE FOR クエリ ヒントで使用する値を割り当てます。
  • literal_constant
    OPTIMIZE FOR クエリ ヒントで使用する、@variable_name に割り当てるリテラル定数値です。literal_constant は、クエリの最適化の過程でのみ使用され、クエリの実行時に @variable_name の値としては使用されません。literal_constant には、リテラル定数として表現できる任意の SQL Server システム データ型を指定できます。literal_constant のデータ型は、@variable_name がクエリ内で参照するデータ型に暗黙的に変換できる必要があります。
  • ,…n
    複数の @variable_name に OPTIMIZE FOR クエリ ヒントで使用する literal_constant を割り当てられることを示します。
  • PARAMETERIZATION { SIMPLE | FORCED }
    クエリのコンパイル時に SQL Server クエリ オプティマイザがそのクエリに適用するパラメータ化のルールを指定します。

    ms181714.note(ja-jp,SQL.90).gif重要 :
    PARAMETERIZATION クエリ ヒントはプラン ガイド内部でのみ指定できます。クエリの中で直接指定することはできません。

    SIMPLE は、クエリ オプティマイザに対して簡易パラメータ化を試行するように指示します。FORCED は、クエリ オプティマイザに対して強制パラメータ化を試行するように指示します。PARAMETERIZATION クエリ ヒントは、プラン ガイド内部の PARAMETERIZATION データベース SET オプションの現在の設定を上書きするのに使用します。詳細については、「プラン ガイドを使用したクエリのパラメータ化動作の指定」を参照してください。

  • RECOMPILE
    クエリの実行後、そのクエリに対して生成されたプランを破棄し、次回同じクエリが実行されたときにクエリ オプティマイザにクエリ プランを再コンパイルさせるよう SQL Server 2005 データベース エンジンに指示します。RECOMPILE を指定しない場合、データベース エンジンはクエリ プランをキャッシュして再利用します。クエリ プランをコンパイルする場合、RECOMPILE クエリ ヒントは、クエリ内のローカル変数の現在値を使用し、クエリがストアド プロシージャ内にある場合は任意のパラメータに渡された現在値を使用します。

    RECOMPILE は、ストアド プロシージャ全体ではなくその中のクエリのサブセットだけを再コンパイルする必要がある場合に、WITH RECOMPILE 句を使用したストアド プロシージャを作成する代わりに使用すると便利です。詳細については、「ストアド プロシージャの再コンパイル」を参照してください。RECOMPILE はプラン ガイドを作成するときにも利用できます。詳細については、「プラン ガイドを使用した配置済みアプリケーションのクエリの最適化」を参照してください。

  • ROBUST PLAN
    クエリ オプティマイザで、最大許容行サイズで動作するプランを試行するよう設定します。ただし、この場合は性能が低下する可能性があります。クエリの処理の際、中間テーブルや演算子が入力行よりも大きな行を格納し、処理しなければならない可能性があります。行があまりに大きいと、演算子によっては行を処理できない場合もあります。このような状態が発生すると、クエリの実行中にデータベース エンジンからエラーが出力されます。ROBUST PLAN を使用することで、クエリ オプティマイザに対して、このような問題を発生するクエリ プランを考慮しないことを指示します。

    このようなプランが可能でない場合は、クエリ実行の後でエラー検出を行うのではなく、クエリ オプティマイザがエラーを返します。行は可変長列で構成されている可能性があります。データベース エンジンでは、データベース エンジンが処理できる範囲を超えた最大可能サイズを持つように、行を定義できます。通常、可能な最大サイズに関係なく、アプリケーションはデータベース エンジンの処理能力で実際に対応できるサイズの行を格納します。データベース エンジンが長すぎる行を検出した場合は、実行エラーが返されます。

  • KEEP PLAN
    クエリ オプティマイザに対して、クエリに推定される再コンパイルしきい値を緩和することを指定します。推定される再コンパイルしきい値とは、UPDATE、DELETE、または INSERT ステートメントの実行により、予測した回数のインデックス列変更がテーブルに加えられた場合に、クエリを自動的に再コンパイルする時点のことです。KEEP PLAN を指定することによって、テーブルに複数の更新が加えられても、クエリは頻繁に再コンパイルされません。
  • KEEPFIXED PLAN
    統計情報の変更に応じてクエリを再コンパイルしないようにクエリ オプティマイザを設定します。KEEPFIXED PLAN を指定することによって、クエリの基になるテーブルが変更された場合、またはそのテーブルに対して sp_recompile が実行された場合のみ、クエリが再コンパイルされます。
  • EXPAND VIEWS
    インデックス付きビューが展開されていることを指定します。これによって、クエリ オプティマイザがインデックス付きビューをクエリの要素の代わりであると見なすことがなくなります。ビューが展開されるのは、ビュー名がクエリ テキスト内のビュー定義に置換される場合です。

    このクエリ ヒントは、インデックス付きビューを直接使用することを実質的に禁止し、クエリ プラン内のインデックス付きビューにインデックスを指定します。

    クエリの SELECT 要素でビューが直接参照され、WITH (NOEXPAND) または WITH (NOEXPAND, INDEX( index_val [ ,...n ] ) ) が指定されている場合のみ、インデックス付きビューは展開されません。クエリ ヒント WITH (NOEXPAND) の詳細については、「FROM (Transact-SQL)」を参照してください。

    INSERT、UPDATE、DELETE ステートメントなど、ステートメントの SELECT 要素内のビューのみが、ヒントの影響を受けます。

  • MAXRECURSION number
    このクエリで許可される最大再帰数を指定します。number は、0 ~ 32,767 の負以外の整数です。0 を指定した場合、制限は適用されません。このオプションが指定されない場合、サーバーの既定の上限値である 100 が使用されます。

    クエリの実行中に MAXRECURSION の指定した上限値または既定上限値に達した場合、クエリは終了し、エラーが返されます。

    このエラーのため、ステートメントのすべての効果がロールバックされます。ステートメントが SELECT ステートメントであった場合、結果の一部が返されるか、結果がまったく返されないかのいずれかになります。結果の一部が返された場合でも、指定した最大再帰レベルを超える再帰レベルのすべての行は含まれていない可能性があります。

    詳細については、「WITH common_table_expression (Transact-SQL)」を参照してください。

  • USE PLAN N**'xml_plan'**
    'xml_plan' で指定されているクエリの既存のクエリ プランを使用するように、クエリ オプティマイザを設定します。詳細については、「プラン強制の使用によるクエリ プランの指定」を参照してください。USE PLAN は、UPDATE、DELETE、または INSERT ステートメントでは指定できません。

解説

ステートメント内部で SELECT 句が使用されている場合を除き、クエリ ヒントは INSERT ステートメントでは指定できません。

クエリ ヒントはサブクエリではなく、トップ レベルのクエリでのみ指定できます。

A. MERGE JOIN を使用する

次の例では、クエリの JOIN 操作を MERGE JOIN によって実行することを指定します。

USE AdventureWorks;
GO
SELECT * 
FROM Sales.Customer AS c
INNER JOIN Sales.CustomerAddress AS ca
ON c.CustomerID = ca.CustomerID
WHERE TerritoryID = 5
OPTION (MERGE JOIN);
GO

B. OPTIMIZE FOR を使用する

次の例では、クエリを最適化する際にローカル変数 @city_name に値 'Seattle' を使用するように、クエリ オプティマイザを設定します。

DECLARE @city_name nvarchar(30)
SET @city_name = 'Ascheim'
SELECT * FROM Person.Address
WHERE City = @city_name
OPTION ( OPTIMIZE FOR (@city_name = 'Seattle') );
GO

C. MAXRECURSION を使用する

MAXRECURSION を使用すると、不適切に作成された再帰共通テーブル式による無限ループの発生を防ぐことができます。次の例では、無限ループを意図的に作成し、MAXRECURSION ヒントを使用して再帰レベルの数を 2 に制限しています。

USE AdventureWorks;
GO
--Creates an infinite loop
WITH cte (EmployeeID, ManagerID, Title) as
(
    SELECT EmployeeID, ManagerID, Title
    FROM HumanResources.Employee
    WHERE ManagerID IS NOT NULL
  UNION ALL
    SELECT cte.EmployeeID, cte.ManagerID, cte.Title
    FROM cte 
    JOIN  HumanResources.Employee AS e 
        ON cte.ManagerID = e.EmployeeID
)
--Uses MAXRECURSION to limit the recursive levels to 2
SELECT EmployeeID, ManagerID, Title
FROM cte
OPTION (MAXRECURSION 2);
GO

コードのエラーが訂正されると、MAXRECURSION は不要になります。

D. UNION を使用する

次の例では、MERGE UNION クエリ ヒントを使用します。

USE AdventureWorks ;
GO
SELECT *
FROM HumanResources.Employee e1
UNION
SELECT *
FROM HumanResources.Employee e2
OPTION (MERGE UNION) ;
GO

E. HASH GROUP および FAST を使用する

次の例では、HASH GROUP および FAST クエリ ヒントを使用します。

USE AdventureWorks ;
GO
SELECT ProductID, OrderQty, SUM(LineTotal) AS Total
FROM Sales.SalesOrderDetail
WHERE UnitPrice < $5.00
GROUP BY ProductID, OrderQty
ORDER BY ProductID, OrderQty
OPTION (HASH GROUP, FAST 10) ;
GO

F. MAXDOP を使用する

次の例では、MAXDOP クエリ ヒントを使用します。

USE AdventureWorks ;
GO
SELECT ProductID, OrderQty, SUM(LineTotal) AS Total
FROM Sales.SalesOrderDetail
WHERE UnitPrice < $5.00
GROUP BY ProductID, OrderQty
ORDER BY ProductID, OrderQty
OPTION (MAXDOP 2);
GO

参照

関連項目

ヒント (Transact-SQL)

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース 履歴

2007 年 9 月 15 日

変更内容 :
  • MAXDOP クエリ ヒントは sp_configure で構成された値を超えると無効になります。

2006 年 7 月 17 日

追加内容 :
  • 例 C. ~ F. を追加しました。