ヒント (Transact-SQL) - Query

[アーティクル]
01/08/2024

適用対象:SQL Server Azure SQL Database Azure SQL Managed Instance

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

注意事項

通常、クエリにとって最適な実行プランが SQL Server クエリオプティマイザーによって選択されるため、ヒントは、経験を積んだ開発者やデータベース管理者が最後の手段としてのみ使用することをお勧めします。

適用対象:

Transact-SQL 構文表記規則

構文

<query_hint> ::=
{ { HASH | ORDER } GROUP
  | { CONCAT | HASH | MERGE } UNION
  | { LOOP | MERGE | HASH } JOIN
  | DISABLE_OPTIMIZED_PLAN_FORCING
  | EXPAND VIEWS
  | FAST <integer_value>
  | FORCE ORDER
  | { FORCE | DISABLE } EXTERNALPUSHDOWN
  | { FORCE | DISABLE } SCALEOUTEXECUTION
  | IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX
  | KEEP PLAN
  | KEEPFIXED PLAN
  | MAX_GRANT_PERCENT = <numeric_value>
  | MIN_GRANT_PERCENT = <numeric_value>
  | MAXDOP <integer_value>
  | MAXRECURSION <integer_value>
  | NO_PERFORMANCE_SPOOL
  | OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ...n ] )
  | OPTIMIZE FOR UNKNOWN
  | PARAMETERIZATION { SIMPLE | FORCED }
  | QUERYTRACEON <integer_value>
  | RECOMPILE
  | ROBUST PLAN
  | USE HINT ( <use_hint_name> [ , ...n ] )
  | USE PLAN N'<xml_plan>'
  | TABLE HINT ( <exposed_object_name> [ , <table_hint> [ [ , ] ...n ] ] )
}

<table_hint> ::=
{ NOEXPAND [ , INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> ) ]
  | INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> )
  | FORCESEEK [ ( <index_value> ( <index_column_name> [ , ... ] ) ) ]
  | FORCESCAN
  | HOLDLOCK
  | NOLOCK
  | NOWAIT
  | PAGLOCK
  | READCOMMITTED
  | READCOMMITTEDLOCK
  | READPAST
  | READUNCOMMITTED
  | REPEATABLEREAD
  | ROWLOCK
  | SERIALIZABLE
  | SNAPSHOT
  | SPATIAL_WINDOW_MAX_CELLS = <integer_value>
  | TABLOCK
  | TABLOCKX
  | UPDLOCK
  | XLOCK
}

<use_hint_name> ::=
{ 'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'
  | 'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'
  | 'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'
  | 'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'
  | 'DISABLE_BATCH_MODE_ADAPTIVE_JOINS'
  | 'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK'
  | 'DISABLE_DEFERRED_COMPILATION_TV'
  | 'DISABLE_INTERLEAVED_EXECUTION_TVF'
  | 'DISABLE_OPTIMIZED_NESTED_LOOP'
  | 'DISABLE_OPTIMIZER_ROWGOAL'
  | 'DISABLE_PARAMETER_SNIFFING'
  | 'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK'
  | 'DISABLE_TSQL_SCALAR_UDF_INLINING'
  | 'DISALLOW_BATCH_MODE'
  | 'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS'
  | 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
  | 'FORCE_DEFAULT_CARDINALITY_ESTIMATION'
  | 'FORCE_LEGACY_CARDINALITY_ESTIMATION'
  | 'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n'
  | 'QUERY_PLAN_PROFILE'
}

Note

SQL Server 2014 (12.x) 以前のバージョンの Transact-SQL 構文を確認するには、以前のバージョンのドキュメントを参照してください。

引数

{ HASH | ORDER } GROUP

クエリの GROUP BY 句または DISTINCT 句に記述されている集計でハッシュまたは順序付けを使用することを指定します。

{ MERGE | HASH | CONCAT } UNION

UNION セットをマージ、ハッシュ、または連結することによって、すべての UNION 操作を実行することを指定します。複数の UNION ヒントを指定した場合、クエリオプティマイザーは指定されたヒントの中から最も負荷の軽い方法を選択します。

{ LOOP | MERGE | HASH } JOIN

LOOP JOIN、MERGE JOIN、または HASH JOIN によって、すべての結合操作がクエリ全体で実行されることを指定します。結合ヒントを複数指定した場合は、可能なヒントの中から最も負荷の軽い方法がオプティマイザーによって選択されます。

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

DISABLE_OPTIMIZED_PLAN_FORCING

適用対象: SQL Server (SQL Server 2022 (16.x) 以降)

クエリのプラン強制の最適化を無効にします。

プラン強制を最適化すると、強制クエリを繰り返すためのコンパイルオーバーヘッドが減ります。クエリ実行プランが生成されると、最適化再生スクリプトとして再利用するために特定のコンパイル手順が格納されます。最適化再生スクリプトは、圧縮されたプラン表示 XML の一部としてクエリストアの非表示 OptimizationReplay 属性に保管されます。

EXPAND VIEWS

インデックス付きビューが展開済みであることを指定します。また、クエリオプティマイザーで、インデックス付きビューがクエリ部分の置換であると見なされないように指定します。ビューが展開されるのは、クエリテキスト内のビュー名がビュー定義で置換される場合です。

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

注意

クエリの SELECT 部分にビューへの直接参照がある場合、インデックス付きビューは縮小されたままです。 WITH (NOEXPAND) または WITH (NOEXPAND, INDEX( <index_value> [ , *...n* ] ) ) を指定した場合も、ビューは縮小されたままになります。クエリヒント NOEXPAND の詳細については、「NOEXPAND の使用」を参照してください。

ヒントは、INSERT、UPDATE、MERGE、および DELETE ステートメントのビューを含め、ステートメントの SELECT 部分のビューにのみ影響します。

FAST <integer_value>

最初の行を高速検索するためにクエリの最適化を行うことを指定します。この結果は負以外の整数です。最初の行を返した後、クエリの実行を続け、完全な結果セットを作成します。

FORCE ORDER

クエリの構文に示されている結合順序が、クエリの最適化中、保持されることを指定します。 FORCE ORDER を使用しても、クエリオプティマイザーのロールの逆引き動作に影響はありません。

注意

MERGE ステートメント内で、WHEN SOURCE NOT MATCHED 句が指定されていない限り、既定の結合順序としてソーステーブルはターゲットテーブルよりも前にアクセスされます。 FORCE ORDER を指定すると、この既定の動作が維持されます。

{FORCE |無効にする EXTERNALPUSHDOWN}

強制または式を使用して hadoop の該当する計算のプッシュダウンを無効にします。 PolyBase を使用してクエリにのみ適用されます。 Azure ストレージにはプッシュダウンされません。

{ FORCE | DISABLE } SCALEOUTEXECUTION

SQL Server 2019 ビッグデータクラスターで外部テーブルを使用している PolyBase クエリのスケールアウト実行を強制または無効にします。このヒントは、SQL ビッグデータクラスターのマスターインスタンスを使用するクエリによってのみ受け入れられます。スケールアウトは、ビッグデータクラスターのコンピューティングプール間で発生します。

KEEP PLAN

一時テーブルの再コンパイルしきい値を変更し、永続的なテーブルと同じにします。推定される再コンパイルしきい値を指定すると、以下のいずれかのステートメントを実行して、予測した回数のインデックス列変更がテーブルに加えられた場合に、クエリの自動再コンパイルが開始されます。

UPDATE
DELETE
MERGE
INSERT

KEEP PLAN を指定することによって、テーブルに複数の更新が加えられても、クエリは頻繁に再コンパイルされません。

KEEPFIXED PLAN

統計情報の変更に応じてクエリを再コンパイルしないようにクエリオプティマイザーを設定します。 KEEPFIXED PLAN を指定することによって、クエリの基になるテーブルのスキーマが変更された場合、またはそのテーブルに対して sp_recompile が実行された場合のみ、クエリが再コンパイルされます。

IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX

適用対象: SQL Server (SQL Server 2012 (11.x) 以降)。

クエリで非クラスター化メモリ最適化列ストアインデックスが使用されないようにします。クエリに、列ストアインデックスの使用を回避するクエリヒントと、列ストアインデックスを使用するインデックスヒントがある場合、ヒントが競合してクエリはエラーを返します。

MAX_GRANT_PERCENT = <numeric_value>

適用対象: SQL Server (SQL Server 2012 (11.x) 以降の Service Pack 3、SQL Server 2014 (12.x) Service Pack 2、Azure SQL データベース）。

構成されているメモリ制限の最大メモリ許可サイズ (%)。クエリがユーザー定義のリソースプールで実行されている場合、クエリはこの制限を超えないように保証されます。この場合、クエリに必要な最小メモリがない場合、システムでエラーが発生します。クエリがシステムプール (既定) で実行されている場合、少なくとも実行に必要なメモリが取得されます。 Resource Governor の設定がこのヒントで指定されている値より小さい場合、実際の制限はこれよりも小さくなる可能性があります。有効な値では、0.0 ～ 100.0 します。

メモリ許可ヒントは、インデックスの作成またはインデックスのリビルドには使用できません。

MIN_GRANT_PERCENT = <numeric_value>

適用対象: SQL Server (SQL Server 2012 (11.x) 以降の Service Pack 3、SQL Server 2014 (12.x) Service Pack 2、Azure SQL データベース）。

構成されているメモリ制限の最小メモリ許可サイズ (%)。クエリを開始するために最小限必要なメモリがあるため、クエリには確実に MAX(required memory, min grant) が割り当てられます。有効な値では、0.0 ～ 100.0 します。

min_grant_percent メモリ許可オプションは、サイズに関係なく、sp_configure オプション (クエリあたりの最小メモリ数 (KB)) をオーバーライドします。メモリ許可ヒントは、インデックスの作成またはインデックスのリビルドには使用できません。

MAXDOP <integer_value>

適用対象: SQL Server (SQL Server 2008 (10.0.x) 以降) および Azure SQL Database。

sp_configure の max degree of parallelism 構成オプションをオーバーライドします。また、このオプションを指定してクエリの Resource Governor もオーバーライドします。 MAXDOP クエリヒントは、sp_configure で構成されている値を超えて指定できます。 MAXDOP では、Resource Governor で構成されている値を超えると、データベースエンジンは、「WORKLOAD GROUP (Transact-SQL)」に記載のリソースガバナーの MAXDOP 値を使用します。 MAXDOP クエリヒントを使用している場合は、max degree of parallelism 構成オプションで使用されるすべての意味ルールを適用できます。詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。

警告

MAXDOP が 0 に設定されている場合、サーバーでは最大限の並列処理が実行されます。

MAXRECURSION <integer_value>

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

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

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

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

NO_PERFORMANCE_SPOOL

適用対象: SQL Server (SQL Server 2016 (13.x) 以降) および Azure SQL データベース。

Spool 操作は、(を除く、計画、スプールが有効な更新のセマンティクスを保証するために必要な場合) のクエリプランに追加されないようにします。スプール演算子は、一部のシナリオでパフォーマンスを低下させることができます。たとえば、スプールで tempdb を使うと、スプール操作が実行されている多くの同時実行クエリがある場合に、tempdb の競合が発生することがあります。

OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ...n ] )

クエリをコンパイルおよび最適化するときにローカル変数に対して特定の値を使用するように、クエリオプティマイザーに指示します。この値はクエリを最適化する過程でのみ使用され、クエリの実行時には使用されません。

@variable_name

OPTIMIZE FOR クエリヒントで使用するために値を割り当てることができる、クエリで使用されるローカル変数の名前。
UNKNOWN

クエリオプティマイザーでのクエリの最適化時に、初期値の代わりに統計データを使用してローカル変数の値を決定することを指定します。
<literal_constant>

OPTIMIZE FOR クエリヒントで使用する @variable_name に割り当てるリテラル定数値。 <literal_constant> は、クエリの最適化の過程でのみ使われ、クエリ実行時に @variable_name の値としては使われません。 <literal_constant> には、リテラル定数として表現できる任意の SQL Server システムデータ型を指定できます。 <literal_constant> のデータ型は、@variable_name がクエリ内で参照するデータ型に暗黙的に変換できる必要があります。

OPTIMIZE FOR は、オプティマイザーの既定のパラメーター検出動作を無効にする場合に使用できます。また、プランガイドを作成するときにも OPTIMIZE FOR を使用します。詳細については、「ストアドプロシージャの再コンパイル」を参照してください。

OPTIMIZE FOR UNKNOWN

クエリをコンパイルおよび最適化するときにランタイムパラメーターの値を使用するのではなく、すべての列の値にわたる述語の平均選択度を使用するようにクエリオプティマイザーに指示します。

同じクエリヒントで OPTIMIZE FOR @variable_name = <literal_constant> と OPTIMIZE FOR UNKNOWN を使用した場合、クエリオプティマイザーでは、特定の値に対しては指定された literal_constant が使われます。クエリオプティマイザーでは、残りの変数値には UNKNOWN が使用されます。これらの値はクエリを最適化する過程でのみ使用され、クエリの実行時には使用されません。

PARAMETERIZATION { SIMPLE | FORCED }

クエリのコンパイル時に SQL Server クエリオプティマイザーがそのクエリに適用するパラメーター化のルールを指定します。

重要

PARAMETERIZATION クエリヒントは、PARAMETERIZATION データベース SET オプションの現在の設定をオーバーライドするため、プランガイドの内部でのみ指定できます。クエリの中で直接指定することはできません。

詳細については、「プランガイドを使用したクエリのパラメーター化動作の指定」を参照してください。

SIMPLE は、クエリオプティマイザーに対して簡易パラメーター化を試行するように指示します。 FORCED は、クエリオプティマイザーに対して強制パラメーター化を試行するように指示します。詳細については、「クエリ処理アーキテクチャガイド」の「強制パラメーター化」および「クエリ処理アーキテクチャガイド」の「簡易パラメーター化」を参照してください。

QUERYTRACEON <integer_value>

このオプションを使用すると、単一クエリのコンパイル中にのみ、プランに影響するトレースフラグを有効にすることができます。他のクエリレベルオプションと同様に、これをプランガイドと共に使用して、任意のセッションから実行されているクエリのテキストを照合し、このクエリのコンパイル時に、プランに影響するトレースフラグを自動的に適用することができます。 QUERYTRACEON オプションは、クエリオプティマイザーのトレースフラグでのみサポートされています。詳しくは、「トレースフラグ」をご覧ください。

サポートされていないトレースフラグ番号が使用された場合、このオプションを使用してエラーや警告が返されることはありません。指定されたトレースフラグがクエリ実行プランに影響を与えるものではない場合、このオプションは自動的に無視されます。

1 つのクエリで複数のトレースフラグを使用するには、異なるトレースフラグ番号ごとに 1 つの QUERYTRACEON ヒントを指定します。

RECOMPILE

SQL Server データベースエンジンに、クエリの新しい一時的なプランを生成し、クエリ実行完了直後にそのプランを破棄するよう指示します。生成されたクエリプランは、RECOMPILE ヒントを指定しないで同じクエリを実行したときにキャッシュに格納されるプランを置き換えません。 RECOMPILE を指定しない場合、データベースエンジンはクエリプランをキャッシュして再利用します。クエリプランをコンパイルする場合、RECOMPILE クエリヒントは、クエリ内のローカル変数の現在値を使用します。クエリがストアドプロシージャ内にある場合は、任意のパラメーターに渡された現在値を使用します。

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

ROBUST PLAN

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

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

USE HINT ( 'hint_name' )

適用対象: SQL Server (SQL Server 2016 (13.x) SP1 以降) および Azure SQL データベース。

1 つ以上の追加のヒントをクエリプロセッサに指定します。追加のヒントは、ヒント名を単一引用符で囲んで指定します。

次のヒント名がサポートされています。

'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'

SQL Server 2014 (12.x) 以降のクエリオプティマイザーのカーディナリティ推定モデルで、結合に対して、既定の基本含有の推定の代わりに、単純な含有の推定を使用して、SQL Server にクエリプランを生成させます。このヒント名は、トレースフラグ 9476 を指定した場合と同じです。
'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'

完全な相関関係を考慮するフィルターの AND 述語を見積もるときに、最低限の選択度を使用して SQL Server にプランを生成させます。このヒント名は、SQL Server 2012 (11.x) 以前のバージョンのカーディナリティ推定モデルでトレースフラグ 4137 を使用した場合と同じで、トレースフラグ 9471 を SQL Server 2014 (12.x) 以降のバージョンのカーディナリティ推定モデルで使用した場合と同じ効果があります。
'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'

完全な独立性を考慮するフィルターの AND 述語を見積もるときに、最大限の選択度を使用して SQL Server にプランを生成させます。このヒント名は、SQL Server 2012 (11.x) のカーディナリティ推定モデルの既定の動作であり、SQL Server 2014 (12.x) 以降のカーディナリティ推定モデルでトレースフラグ 9472 を使用したときと同等です。

適用対象: Azure SQL データベース
'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'

部分的な相関関係を考慮するフィルターの AND 述語を見積もるときに、すべての選択度を使用して SQL Server にプランを生成させます。このヒント名は、SQL Server 2014 (12.x) 以降のカーディナリティ推定モデルの既定の動作です。

適用対象: Azure SQL データベース
'DISABLE_BATCH_MODE_ADAPTIVE_JOINS'

バッチモードアダプティブ結合を無効にします。詳細については、「バッチモードアダプティブ結合」を参照してください。

適用対象: SQL Server (SQL Server 2017 (14.x) 以降) および Azure SQL データベース
'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK'

バッチモードメモリ許可フィードバックを無効にします。詳細については、「バッチモードメモリ許可フィードバック」を参照してください。

適用対象: SQL Server (SQL Server 2017 (14.x) 以降) および Azure SQL データベース
'DISABLE_DEFERRED_COMPILATION_TV'

テーブル変数の遅延コンパイルを無効にします。詳細については、「テーブル変数の遅延コンパイル」をご覧ください。

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース
'DISABLE_INTERLEAVED_EXECUTION_TVF'

複数ステートメントのテーブル値関数のインターリーブ実行を無効にします。詳細については、「複数ステートメントのテーブル値関数のインターリーブ実行」を参照してください。

適用対象: SQL Server (SQL Server 2017 (14.x) 以降) および Azure SQL データベース
'DISABLE_OPTIMIZED_NESTED_LOOP'

クエリプランを生成するときに、最適化された入れ子になったループ結合に対して並べ替え操作 (バッチソート) を使用しないように、クエリプロセッサに指示します。このヒント名は、トレースフラグ 2340 を指定した場合と同じです。
'DISABLE_OPTIMIZER_ROWGOAL'

次のいずれかのキーワードを含むクエリで行の目標の変更を使用しないプランを SQL Server に生成させます。
- TOP
- OPTION (FAST N)
- IN
- EXISTS
このヒント名は、トレースフラグ 4138 を指定した場合と同じです。
'DISABLE_PARAMETER_SNIFFING'

1 つまたは複数のパラメーターを指定してクエリをコンパイルする際に、平均データ分布を使用するようにクエリオプティマイザーに指示します。この指示により、クエリをコンパイルするときに最初に使用されていたパラメーター値にクエリプランが依存しなくなります。このヒント名は、トレースフラグ 4136 を指定した場合、またはデータベーススコープ構成を PARAMETER_SNIFFING = OFF に設定した場合と同じです。
'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK'

行モードメモリ許可フィードバックを無効にします。詳細については、「行モードメモリ許可フィードバック」を参照してください。

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース
'DISABLE_TSQL_SCALAR_UDF_INLINING'

スカラー UDF のインライン化を無効にします。詳細については、「スカラー UDF のインライン化」を参照してください。

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース
'DISALLOW_BATCH_MODE'

バッチモード実行を無効にします。詳細については、「実行モード」を参照してください。

適用対象: SQL Server (SQL Server 2019 (15.x) 以降) および Azure SQL データベース
'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS'

カーディナリティ推定が必要なすべての先頭のインデックス列に対して、クイック統計情報 (ヒストグラム修正) を自動的に生成できるようにします。カーディナリティを推定するために使用されるヒストグラムは、この列の実際の最大値または最小値を考慮するクエリのコンパイル時に調整されます。このヒント名は、トレースフラグ 4139 を指定した場合と同じです。
'ENABLE_QUERY_OPTIMIZER_HOTFIXES'

クエリオプティマイザー修正プログラム (SQL Server の累積的な更新プログラムとサービスパックでリリースされた変更) を有効にします。このヒント名は、トレースフラグ 4199 を指定した場合、またはデータベーススコープ構成を QUERY_OPTIMIZER_HOTFIXES = ON に設定した場合と同じです。
'FORCE_DEFAULT_CARDINALITY_ESTIMATION'

現在のデータベース互換性レベルに対応するカーディナリティ推定モデルを使用するようにクエリオプティマイザーを設定します。このヒントを使用して、データベーススコープ構成の LEGACY_CARDINALITY_ESTIMATION = ON 設定またはトレースフラグ 9481 をオーバーライドします。
'FORCE_LEGACY_CARDINALITY_ESTIMATION'

SQL Server 2012 (11.x) 以前のバージョンのカーディナリティ推定モデルを使用するようにクエリオプティマイザーを設定します。このヒント名は、トレースフラグ 9481 を指定した場合、またはデータベーススコープ構成を LEGACY_CARDINALITY_ESTIMATION = ON に設定した場合と同じです。
'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n'

クエリレベルでクエリオプティマイザーの動作を強制します。この動作は、クエリがデータベース互換レベル n でコンパイルされているかのように実行されます。ここでの n はサポートされているデータベース互換レベルです (例: 100、130 など)。現在サポートされている n の値の一覧については、「sys.dm_exec_valid_use_hints」をご覧ください。

適用対象: SQL Server (SQL Server 2017 (14.x) CU10 以降) および Azure SQL データベース

注意

既定またはレガシのカーディナリティ推定の設定が、データベーススコープ構成、トレースフラグ、または QUERYTRACEON などの別のクエリヒントによって適用されている場合、QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n ヒントはそれをオーバーライドしません。
このヒントは、クエリオプティマイザーの動作にのみ影響します。特定のデータベース機能の可用性など、データベース互換レベルに依存する可能性のある SQL Server の他の機能には影響しません。
このヒントの詳細については、「Developer’s Choice:Hinting Query Execution model」(開発者の選択: クエリヒント実行モデル) をご覧ください。
'QUERY_PLAN_PROFILE'

クエリの軽量プロファイリングを有効にします。この新しいヒントを含むクエリが完了したら、新しい拡張イベントである query_plan_profile が起動されます。この拡張イベントでは、実行の統計と query_post_execution_showplan 拡張イベントのような実際の実行プラン XML が公開されますが、新しいヒントを含むクエリのみが対象です。

適用対象: SQL Server (SQL Server 2016 (13.x) SP2 CU3 および SQL Server 2017 (14.x) CU11 以降)。

Note

拡張イベントの query_post_execution_showplan 収集を有効にすると、サーバーで実行されているすべてのクエリに標準プロファイルインフラストラクチャが追加されるため、サーバーの全体的なパフォーマンスに影響する可能性があります。
拡張イベントの query_thread_profile 収集を有効にして軽量プロファイリングインフラストラクチャを代わりに使用すると、パフォーマンスのオーバーヘッドは大幅に少なくなりますが、サーバーの全体的なパフォーマンスに影響を与えます。
拡張イベントを query_plan_profile 有効にした場合、これにより、サーバーで query_plan_profile 実行されたクエリに対してのみ軽量プロファイリングインフラストラクチャが有効になります。そのため、サーバー上の他のワークロードには影響しません。このヒントを使用して、サーバーワークロードの他の部分に影響を与えずに特定のクエリをプロファイリングします。軽量プロファイリングの詳細については、「クエリプロファイリングインフラストラクチャ」をご覧ください。

サポートされているすべての USE HINT 名の一覧は、動的管理ビューの sys.dm_exec_valid_use_hints を使用して照会できます。

ヒント

ヒント名では大文字と小文字が区別されません。

重要

一部の U Standard Edition HINT ヒントは、グローバルレベルまたはセッションレベルで有効になっているトレースフラグ、またはデータベーススコープの構成設定と競合する可能性があります。この場合、クエリレベルヒント (USE HINT) が常に優先されます。 USE HINT が別のクエリヒントまたはクエリレベルで (QUERYTRACEON などによって) 有効になっているトレースフラグと競合する場合、クエリを実行しようとすると、SQL Server によってエラーが生成されます。

USE PLAN N'<xml_plan>'

'<xml_plan>' で指定されているクエリの既存のクエリプランを使うように、クエリオプティマイザーを設定します。 USE PLAN は、INSERT、UPDATE、MERGE、または DELETE の各ステートメントに指定することはできません。

この機能によって強制され、生成される実行プランは、強制されているプランと同じか、または似たものになります。結果のプランは U Standard Edition PLAN で指定されたプランと同じでない可能性があるため、プランのパフォーマンスは異なる場合があります。まれに、パフォーマンスの違いは大きく、負の場合もあります。その場合、管理者は強制プランを削除する必要があります。

TABLE HINT (<exposed_object_name> [ , <table_hint> [ [, ]...n ] ] )

exposed_object_name に対応するテーブルまたはビューに、指定したテーブルヒントを適用します。プランガイドのコンテキスト内でのみ、テーブルヒントをクエリヒントとして使用することをお勧めします。

<exposed_object_name> には、次のいずれかの参照を指定できます。

クエリの FROM 句内でテーブルまたはビューに対して別名を使用する場合、exposed_object_name は別名です。
別名を使用しない場合、exposed_object_name は、FROM 句で参照されているテーブルまたはビューと完全に一致している必要があります。たとえば、2 つの部分で構成される名前を使用してテーブルまたはビューが参照されている場合、exposed_object_name は、2 つの部分で構成される同じ名前です。

テーブルヒントも指定せずに exposed_object_name を指定した場合、オブジェクトのテーブルヒントの一部としてクエリに指定された任意のインデックスは無視されます。次に、クエリオプティマイザーによってインデックスの使用が決まります。この手法を使用すると、元のクエリに変更を加えることができない場合に INDEX テーブルヒントの効果を除去できます。例 J を参照してください。

<table_hint>

クエリヒントとして exposed_object_name に対応するテーブルまたはビューに適用するテーブルヒントです。これらのヒントの説明については、「テーブルヒント (Transact-SQL)」を参照してください。

INDEX、FORCESCAN、および FORCESEEK 以外のテーブルヒントは、クエリで既に WITH 句を使用してテーブルヒントが指定されていない限り、クエリヒントとして使用できません。詳細については、「解説」を参照してください。

注意事項

パラメーターを使用して FORCESEEK を指定すると、クエリオプティマイザーで考慮できるプラン数の制限は、パラメーターなしで FORCESEEK を指定した場合よりも多くなります。これにより、より多くの場合に "プランを生成できません" というエラーが発生する可能性があります。

解説

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

クエリヒントはサブクエリではなく、最上位レベルのクエリでのみ指定できます。テーブルヒントがクエリヒントとして指定されている場合、ヒントは最上位レベルのクエリまたはサブクエリで指定できます。ただし、TABLE HINT 句の <exposed_object_name> に指定された値は、クエリまたはサブクエリの公開名と完全に一致する必要があります。

クエリヒントとしてテーブルヒントを指定する

プランガイドのコンテキスト内でのみ、INDEX、FORCESCAN、または FORCESEEK テーブルヒントをクエリヒントとして使用することをお勧めします。プランガイドは、たとえばクエリがサードパーティアプリケーションである場合のように、元のクエリに変更を加えることができない場合に便利です。プランガイドに指定されたクエリヒントは、コンパイルおよび最適化される前にクエリに追加されます。アドホッククエリの場合は、プランガイドステートメントをテストするときだけ TABLE HINT 句を使用します。その他のアドホッククエリに対しては、テーブルヒントとしてのみこれらのヒントを指定することをお勧めします。

クエリヒントとして指定した場合、INDEX、FORCESCAN、および FORCESEEK テーブルヒントは次のオブジェクトに対して有効です。

テーブル
ビュー
インデックス付きビュー
共通テーブル式 (ヒントは、結果セットが共通テーブル式に入力される SELECT ステートメントに指定する必要があります)
動的管理ビュー (DMV)
名前付きサブクエリ

既存のテーブルヒントがないクエリのクエリヒントとして、INDEX、FORCESCAN、および FORCESEEK のテーブルヒントを指定できます。また、それらを使用して、クエリ内の既存の INDEX、FORCESCAN、または FORCESEEK ヒントをそれぞれ置き換えることもできます。

INDEX、FORCESCAN、および FORCESEEK 以外のテーブルヒントは、クエリで既に WITH 句を使用してテーブルヒントが指定されていない限り、クエリヒントとして使用できません。この場合、一致するヒントもクエリヒントとして指定する必要があります。 OPTION 句で TABLE HINT を使用して、一致するヒントをクエリヒントとして指定します。この指定はクエリのセマンティクスを保持します。たとえば、クエリにテーブルヒント NOLOCK が含まれている場合、プランガイドの @hints パラメーターの OPTION 句にも NOLOCK ヒントが含まれている必要があります。例 K を参照してください。

クエリストアのヒントでヒントを指定する

クエリストアのヒント機能を利用することで、コードを変更することなく、クエリストアで特定されたクエリにヒントを適用できます。クエリにヒントを適用するには sys.sp_query_store_set_hints ストアドプロシージャを使用します。例 N を参照してください。

例

A. MERGE JOIN を使用する

次の例では、クエリの JOIN 操作を MERGE JOIN によって実行することを指定します。この例では、AdventureWorks2022 データベースを使用します。

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' を使用し、@postal_code にはすべての列の値にわたる述語の平均選択度を使用するように指定しています。この例では、AdventureWorks2022 データベースを使用します。

CREATE PROCEDURE dbo.RetrievePersonAddress
@city_name NVARCHAR(30),
@postal_code NVARCHAR(15)
AS
SELECT * FROM Person.Address
WHERE City = @city_name AND PostalCode = @postal_code
OPTION ( OPTIMIZE FOR (@city_name = 'Seattle', @postal_code UNKNOWN) );
GO

C. MAXRECURSION を使用する

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

--Creates an infinite loop
WITH cte (CustomerID, PersonID, StoreID) AS
(
    SELECT CustomerID, PersonID, StoreID
    FROM Sales.Customer
    WHERE PersonID IS NOT NULL
  UNION ALL
    SELECT cte.CustomerID, cte.PersonID, cte.StoreID
    FROM cte
    JOIN  Sales.Customer AS e
        ON cte.PersonID = e.CustomerID
)
--Uses MAXRECURSION to limit the recursive levels to 2
SELECT CustomerID, PersonID, StoreID
FROM cte
OPTION (MAXRECURSION 2);
GO

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

D. MERGE UNION を使用する

次の例では、MERGE UNION クエリヒントを使用します。この例では、AdventureWorks2022 データベースを使用します。

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

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

次の例では、HASH GROUP および FAST クエリヒントを使用します。この例では、AdventureWorks2022 データベースを使用します。

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 クエリヒントを使用します。この例では、AdventureWorks2022 データベースを使用します。

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

G. INDEX を使用する

次の例では、INDEX ヒントを使用します。最初の例では、単一のインデックスを指定します。 2 番目の例では、1 つのテーブル参照に対して複数のインデックスを指定します。どちらの例においても別名が使用されているテーブルに INDEX ヒントを適用するので、公開されたオブジェクト名と同じ別名を TABLE HINT 句でも指定する必要があります。この例では、AdventureWorks2022 データベースを使用します。

EXEC sp_create_plan_guide
    @name = N'Guide1',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 2;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT(e, INDEX (IX_Employee_ManagerID)))';
GO
EXEC sp_create_plan_guide
    @name = N'Guide2',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 2;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT(e, INDEX(PK_Employee_EmployeeID, IX_Employee_ManagerID)))';
GO

H. FORCESEEK を使用する

次の例では、FORCESEEK テーブルヒントを使用します。公開されたオブジェクト名と同じ 2 つの部分で構成される名前を TABLE HINT 句でも指定する必要があります。この名前は、2 つの部分で構成される名前が使用されているテーブルに INDEX ヒントを適用するときに指定します。この例では、AdventureWorks2022 データベースを使用します。

EXEC sp_create_plan_guide
    @name = N'Guide3',
    @stmt = N'SELECT c.LastName, c.FirstName, HumanResources.Employee.Title
              FROM HumanResources.Employee
              JOIN Person.Contact AS c ON HumanResources.Employee.ContactID = c.ContactID
              WHERE HumanResources.Employee.ManagerID = 3
              ORDER BY c.LastName, c.FirstName;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT( HumanResources.Employee, FORCESEEK))';
GO

I. 複数のテーブルヒントを使用する

次の例では、INDEX ヒントと FORCESEEK ヒントをそれぞれ別のテーブルに適用します。この例では、AdventureWorks2022 データベースを使用します。

EXEC sp_create_plan_guide
    @name = N'Guide4',
    @stmt = N'SELECT e.ManagerID, c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 3;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT (e, INDEX( IX_Employee_ManagerID))
                       , TABLE HINT (c, FORCESEEK))';
GO

J. TABLE HINT を使用して既存のテーブルヒントをオーバーライドする

TABLE HINT ヒントの使用例を次に示します。ヒントを指定せずにヒントを使用すると、クエリの FROM 句で指定した INDEX テーブルヒントの動作をオーバーライドできます。この例では、AdventureWorks2022 データベースを使用します。

EXEC sp_create_plan_guide
    @name = N'Guide5',
    @stmt = N'SELECT e.ManagerID, c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e WITH (INDEX (IX_Employee_ManagerID))
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 3;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT(e))';
GO

K. セマンティックに作用するテーブルヒントを指定する

次の例では、クエリに 2 つのテーブルヒントが含まれています。1 つは、セマンティックに作用する NOLOCK で、もう 1 つはセマンティックに作用しない INDEX です。クエリのセマンティックを保持するために、プランガイドの OPTIONS 句に NOLOCK ヒントが指定されています。 NOLOCK ヒントに加えて、INDEX および FORCESEEK ヒントを指定し、ステートメントのコンパイルおよび最適化中にクエリのセマンティックに作用しない INDEX ヒントを置き換えます。この例では、AdventureWorks2022 データベースを使用します。

EXEC sp_create_plan_guide
    @name = N'Guide6',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
                   WITH (NOLOCK, INDEX (PK_Employee_EmployeeID))
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 3;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT (e, INDEX(IX_Employee_ManagerID), NOLOCK, FORCESEEK))';
GO

次の例では、クエリのセマンティックを保持し、テーブルヒントに指定されている以外のインデックスをオプティマイザーが選択できるようにする別の方法を示します。 OPTIONS 句に NOLOCK ヒントを指定して、オプティマイザーが選択できるようにします。これはセマンティックに作用するので、ヒントを指定します。次に、テーブル参照のみを指定し、INDEX ヒントを指定せずに TABLE HINT キーワードを指定します。この例では、AdventureWorks2022 データベースを使用します。

EXEC sp_create_plan_guide
    @name = N'Guide7',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
                   WITH (NOLOCK, INDEX (PK_Employee_EmployeeID))
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 2;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT (e, NOLOCK))';
GO

L. USE HINT を使用する

次の例では、RECOMPILE および USE HINT のクエリヒントを使用します。この例では、AdventureWorks2022 データベースを使用します。

SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (RECOMPILE, USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES', 'DISABLE_PARAMETER_SNIFFING'));
GO

M. QUERYTRACEON HINT を使用する

次の例では、QUERYTRACEON クエリヒントを使用します。この例では、AdventureWorks2022 データベースを使用します。次のクエリを使用して、特定のクエリに対し、トレースフラグ 4199 によって制御される、プランに影響するすべての修正プログラムを有効にすることができます。

SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (QUERYTRACEON 4199);

次のクエリのように、複数のトレースフラグを使用することもできます。

SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION  (QUERYTRACEON 4199, QUERYTRACEON 4137);

北クエリストアヒントを使用する

Azure SQL Database のクエリストアのヒント機能は、アプリケーションコードを変更することなく、クエリプランを簡単に整形できる方法を提供します。

まず、クエリストアのカタログビューで既に実行されているクエリを特定します。次に例を示します。

SELECT q.query_id, qt.query_sql_text
FROM sys.query_store_query_text qt
INNER JOIN sys.query_store_query q ON
    qt.query_text_id = q.query_text_id
WHERE query_sql_text like N'%ORDER BY ListingPrice DESC%'
  AND query_sql_text not like N'%query_store%';
GO

次の例では、クエリストアで特定された query_id 39 にレガシカーディナリティ推定機能を強制するヒントが適用されています。

EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(USE HINT(''FORCE_LEGACY_CARDINALITY_ESTIMATION''))';

次の例では、クエリヒントで特定された query_id 39 に、設定済みメモリ上限の最大メモリ付与サイズ (%) を強制するヒントが適用されています。

EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(MAX_GRANT_PERCENT=10)';

次の例では、RECOMPILE、MAXDOP 1、SQL 2012 クエリオプティマイザービヘイビアーなど、複数のクエリヒントが query_id 39 に適用されています。

EXEC sys.sp_query_store_set_hints @query_id= 39,
    @query_hints = N'OPTION(RECOMPILE, MAXDOP 1, USE HINT(''QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110''))';