クエリ ヒント (Transact-SQL)

  • [アーティクル]

適用対象: 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 ] ] )
  | FOR TIMESTAMP AS OF '<point_in_time>'
}

<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'
}

引数

{ 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 つのテーブルの結合よりも優先されます。 ただし、クエリ ヒントは引き続き有効です。 テーブルのペアの結合ヒントは、クエリ ヒント内で許可される結合方法の選択を制限できるだけです。 詳細については、「 参加ヒントを参照してください。

DISABLE_OPTIMIZED_PLAN_FORCING

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

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

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

EXPAND VIEWS

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

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

Note

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

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

FAST integer_value

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

FORCE ORDER

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

Note

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を指定すると、1 つのテーブルに対して複数の更新がある場合に、クエリが頻繁に再コンパイルされないようにします。

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 データベース）。

構成されたメモリ制限の PERCENT の最大メモリ許可サイズ。 クエリがユーザー定義のリソース プールで実行されている場合、クエリはこの制限を超えないように保証されます。 この場合、クエリに必要な最小メモリがない場合、システムでエラーが発生します。 クエリがシステム プール (既定) で実行されている場合、少なくとも実行に必要なメモリが取得されます。 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 データベース）。

構成されているメモリ制限の PERCENT の最小メモリ許可サイズ。 クエリを開始するために最小限必要なメモリがあるため、クエリには確実に 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リソース ガバナーで構成された値を超える場合、データベース エンジンはリソース ガバナーのMAXDOP値を使用します(ALTER WORKLOAD GROUPで説明されています。 MAXDOP クエリ ヒントを使用する場合、max 度の並列処理構成オプションで使用されるすべてのセマンティック ルールが適用されます。 詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。

警告

MAXDOPが 0 に設定されている場合、サーバーは並列処理の最大次数を選択します。

MAXRECURSION <integer_value>

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

クエリの実行中に、 MAXRECURSION 制限の指定または既定の数に達すると、クエリが終了し、エラーが返されます。

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

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

NO_PERFORMANCE_SPOOL

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

Spool 操作は、(を除く、計画、スプールが有効な更新のセマンティクスを保証するために必要な場合) のクエリ プランに追加されないようにします。 一部のシナリオでは、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 つの QUERYTRACEON ヒントを指定します。

RECOMPILE

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

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

ROBUST PLAN

クエリ オプティマイザーで、最大許容行サイズで動作するプランを試行するよう設定します。ただし、この場合は性能が低下する可能性があります。 中間テーブルや演算子が入力行よりも大きな行を格納し、処理しなければならない可能性があります。 行があまりに大きいと、演算子によっては行を処理できない場合もあります。 行がそれほど大きい場合、クエリの実行中に データベース エンジン からエラーが出力されます。 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) 以降のバージョンのクエリ オプティマイザー Cardinality Estimation モデルで、結合の既定の基本包含の前提条件ではなく、単純包含の前提条件を使用してクエリ プランを生成します。 このヒント名は、 Trace Flag 9476 と同じです。
'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES' 完全な相関関係を考慮するフィルターの AND 述語を見積もるときに、最低限の選択度を使用して SQL Server にプランを生成させます。 このヒント名は、SQL Server 2012 (11.x) 以前のバージョンのカーディナリティ推定モデルと共に使用する場合、 Trace フラグ 4137 に相当し、sql Server 2014 (12.x) 以降のバージョンのカーディナリティ推定モデルで Trace Flag 9471 を使用する場合も同様の効果があります。
'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES' 完全な独立性を考慮するフィルターの AND 述語を見積もるときに、最大限の選択度を使用して SQL Server にプランを生成させます。 このヒント名は、SQL Server 2012 (11.x) 以前のバージョンのカーディナリティ推定モデルの既定の動作であり、SQL Server 2014 (12.x) 以降のバージョンのカーディナリティ推定モデルで使用される場合は、 Trace フラグ 9472 に相当します。

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

適用対象: Azure SQL Database
'DISABLE_BATCH_MODE_ADAPTIVE_JOINS' バッチ モード アダプティブ結合を無効にします。 詳細については、「バッチ モード アダプティブ結合」を参照してください。

適用対象: SQL Server 2017 (14.x) 以降のバージョンと Azure SQL Database
'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK' バッチ モード メモリ許可フィードバックを無効にします。 詳細については、「バッチ モード メモリ許可フィードバック」を参照してください。

適用対象: SQL Server 2017 (14.x) 以降のバージョンと Azure SQL Database
'DISABLE_DEFERRED_COMPILATION_TV' テーブル変数の遅延コンパイルを無効にします。 詳細については、「テーブル変数の遅延コンパイル」をご覧ください。

適用対象: SQL Server 2019 (15.x) 以降のバージョンと Azure SQL Database
'DISABLE_INTERLEAVED_EXECUTION_TVF' 複数ステートメントのテーブル値関数のインターリーブ実行を無効にします。 詳細については、「複数ステートメントのテーブル値関数のインターリーブ実行」を参照してください。

適用対象: SQL Server 2017 (14.x) 以降のバージョンと Azure SQL Database
'DISABLE_OPTIMIZED_NESTED_LOOP' クエリ プランを生成するときに、最適化された入れ子になったループ結合に対して並べ替え操作 (バッチ ソート) を使用しないように、クエリ プロセッサに指示します。 このヒント名は、 Trace Flag 2340 と同じです。 このヒントは、明示的な並べ替えとバッチの並べ替えにも適用されます。
'DISABLE_OPTIMIZER_ROWGOAL' 次のいずれかのキーワードを含むクエリで行の目標の変更を使用しないプランを SQL Server に生成させます。

- TOP
- OPTION (FAST N)
- IN
- EXISTS

このヒント名は、 Trace フラグ 4138 と同じです。
'DISABLE_PARAMETER_SNIFFING' 1 つまたは複数のパラメーターを指定してクエリをコンパイルする際に、平均データ分布を使用するようにクエリ オプティマイザーに指示します。 この指示により、クエリをコンパイルするときに最初に使用されていたパラメーター値にクエリ プランが依存しなくなります。 このヒント名は、 Trace Flag 4136 または database スコープ構成 設定 PARAMETER_SNIFFING = OFFと同じです。
'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK' 行モード メモリ許可フィードバックを無効にします。 詳細については、「行モード メモリ許可フィードバック」を参照してください。

適用対象: SQL Server 2019 (15.x) 以降のバージョンと Azure SQL Database
'DISABLE_TSQL_SCALAR_UDF_INLINING' スカラー UDF のインライン化を無効にします。 詳細については、「スカラー UDF のインライン化」を参照してください。

適用対象: SQL Server 2019 (15.x) 以降のバージョンと Azure SQL Database
'DISALLOW_BATCH_MODE' バッチ モード実行を無効にします。 詳細については、「実行モード」を参照してください。

適用対象: SQL Server 2019 (15.x) 以降のバージョンと Azure SQL Database
'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS' カーディナリティ推定が必要なすべての先頭のインデックス列に対して、クイック統計情報 (ヒストグラム修正) を自動的に生成できるようにします。 カーディナリティの推定に使用されるヒストグラムは、クエリのコンパイル時に、この列の実際の最大値または最小値を考慮して調整されます。 このヒント名は、 Trace フラグ 4139 と同じです。
'ENABLE_QUERY_OPTIMIZER_HOTFIXES' クエリ オプティマイザー修正プログラム (SQL Server の累積的な更新プログラムとサービス パックでリリースされた変更) を有効にします。 このヒント名は、 Trace Flag 4199 または database スコープ構成 設定 QUERY_OPTIMIZER_HOTFIXES = ONと同じです。
'FORCE_DEFAULT_CARDINALITY_ESTIMATION' 現在のデータベース互換性レベルに対応するカーディナリティ推定モデルを使用するようにクエリ オプティマイザーを設定します。 このヒントを使用して、 データベース スコープの構成 LEGACY_CARDINALITY_ESTIMATION = ON または Trace Flag 9481 の設定をオーバーライドします。
'FORCE_LEGACY_CARDINALITY_ESTIMATION' SQL Server 2012 (11.x) 以前のバージョンの カーディナリティ推定モデルを使用するようにクエリ オプティマイザーを設定します。 このヒント名は、 Trace Flag 9481 または database スコープ構成 設定 LEGACY_CARDINALITY_ESTIMATION = ONと同じです。
'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n' 1 クエリ レベルでクエリ オプティマイザーの動作を強制します。 この動作は、クエリがデータベース互換レベル n でコンパイルされている場合と同様に実行されます (n はサポートされているデータベース互換レベルです)。 nで現在サポートされている値の一覧については、sys.dm_exec_valid_use_hintsを参照してください。

適用対象: SQL Server 2017 (14.x) CU 10 以降のバージョン、および Azure SQL Database
'QUERY_PLAN_PROFILE' 2 クエリの軽量プロファイリングを有効にします。 この新しいヒントを含むクエリが完了すると、新しい拡張イベント query_plan_profileが発生します。 この拡張イベントは、 query_post_execution_showplan 拡張イベントに似た実行統計と実際の実行プラン XML を公開しますが、新しいヒントを含むクエリに対してのみ公開されます。

適用対象: SQL Server 2016 (13.x) SP 2 CU 3、SQL Server 2017 (14.x) CU 11 以降のバージョン

1 データベース スコープの構成、トレース フラグ、または他のクエリ ヒント (QUERYTRACEON など) を使用して強制的に設定した場合、QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n ヒントは既定またはレガシカーディナリティ推定設定をオーバーライドしません。 このヒントは、クエリ オプティマイザーの動作にのみ影響します。 特定のデータベース機能の可用性など、データベース互換レベルに依存する可能性のある SQL Server の他の機能には影響しません。 詳細については、「 Developer の選択肢: クエリ実行モデルのヒント」を参照してください。

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

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

重要

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

USE PLAN N'xml_plan'

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

この機能によって強制される実行プランは、強制されるプランと同じか類似しています。 結果として得られるプランは、 USE 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 テーブル ヒントの効果を排除できます。 Example Jを参照してください。

<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

クエリ ヒントとして exposed_object_name に対応するテーブルまたはビューに適用するテーブル ヒント。 これらのヒントの詳細については、 Table ヒントを参照してください。

INDEX、FORCESCAN、FORCESEEK以外のテーブル ヒントは、クエリヒントを指定するWITH句が既に存在しない限り、クエリ ヒントとして許可されません。 詳細については、「解説」を参照してください。

注意事項

パラメーターで FORCESEEK を指定すると、パラメーターを指定せずに FORCESEEK を指定する場合よりも、クエリ オプティマイザーで考慮できるプランの数が制限されます。 これにより、"プランを生成できない" というエラーが生じる回数が増加する可能性があります。

'point_in_time' のタイムスタンプの場合

適用対象:Microsoft Fabric のウェアハウス

OPTION 句の TIMESTAMP 構文を使用して、Microsoft Fabric の Synapse Data Warehouse の時間移動機能の一部として、過去に存在していたデータに対してクエリを実行します。

その時点で表示されたデータを返す形式 yyyy-MM-ddTHH:mm:ss[.fff] で point_in_time を指定します。 タイム ゾーンは常に UTC です。 スタイル 126 の必要な datetime 形式の CONVERT 構文を使用します。

TIMESTAMP AS OF ヒントは、OPTION 句を使用して 1 回だけ指定できます。 詳細と制限については、「過去に存在していたデータに対してクエリを実行する」を参照してください。

解説

ステートメント内で 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 ヒントが含まれている必要があります。 「 Example K」を参照してください。

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

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

例

A. MERGE JOIN を使用する

次の例では、 MERGE JOIN クエリで 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 テーブル ヒントを使用します。 TABLE HINT句では、公開されているオブジェクト名と同じ 2 部構成の名前も指定する必要があります。 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 ヒントを 1 つのテーブルに適用し、 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. セマンティックに作用するテーブル ヒントを指定する

次の例には、セマンティックに影響を与える NOLOCK と、セマンティックに影響しない INDEXという 2 つのテーブル ヒントがクエリに含まれています。 クエリのセマンティクスを保持するために、プラン ガイドの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''))';

次の例では、ヒントを適用して、構成されたメモリ制限のPERCENTで最大メモリ許可サイズを 39 query_id (クエリ ストアで識別) に適用します。

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

次の例では、 RECOMPILE、 MAXDOP 1、SQL Server 2012 (11.x) クエリ オプティマイザーの動作など、複数のクエリ ヒントを 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''))';

O. 特定の時点のデータのクエリを実行する

適用対象:Microsoft Fabric のウェアハウス

TIMESTAMP 句の OPTION 構文を使用して、Microsoft Fabric の Synapse Data Warehouse で、過去に存在していたデータのクエリを実行します。 次のサンプル クエリでは、2024 年 3 月 13 日 7:39:35.28 PM UTC に表示されたデータが返されます。 タイム ゾーンは常に UTC です。

SELECT OrderDateKey, SUM(SalesAmount) AS TotalSales
FROM FactInternetSales
GROUP BY OrderDateKey
ORDER BY OrderDateKey
OPTION (FOR TIMESTAMP AS OF '2024-03-13T19:39:35.28');--March 13, 2024 at 7:39:35.28 PM UTC

関連するコンテンツ