クエリヒント (Transact-SQL)

[アーティクル]
03/22/2025

適用対象:SQL Server Azure SQL Database Azure SQL Managed Instance Microsoft Fabric の SQL 分析エンドポイント Microsoft Fabric のウェアハウス Microsoft Fabric のSQL データベース

クエリヒントは、指定されたヒントをクエリのスコープで使用することを指定します。これらは、ステートメント内のすべての演算子に影響します。メインクエリに UNION が関係している場合、UNION 操作に関連する最後のクエリにのみ OPTION 句を指定できます。クエリヒントは、OPTION 句の一部として指定されます。エラー 8622 は、1 つ以上のクエリヒントによってクエリオプティマイザーで有効なプランが生成されない場合に発生します。

注意事項

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 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 属性に保管されます。

ビューの展開

インデックス付きビューが展開されるように指定します。また、クエリオプティマイザーがインデックス付きビューをクエリパーツの代わりと見なさないことも指定します。ビューは、クエリテキスト内のビュー名がビュー定義によって置き換えられるときに展開されます。

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

注

クエリの 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 を使用しても、クエリオプティマイザーのロールの反転動作には影響しません。

FORCE ORDER クエリで指定された結合順序が保持されるため、複雑な結合条件やヒントを含むクエリのパフォーマンスや一貫性が向上する可能性があります。

注

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

{ FORCE |DISABLE } EXTERNALPUSHDOWN

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

{ FORCE |DISABLE } SCALEOUTEXECUTION

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

プランの保持

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

UPDATE
DELETE
MERGE
INSERT

KEEP PLAN を指定すると、テーブルに複数の更新がある場合にクエリが頻繁に再コンパイルされないようにします。

KEEPFIXED プラン

統計の変更により、クエリオプティマイザーがクエリを再コンパイルしないように強制します。 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 Database 以降)。

構成されているメモリ制限の PERCENT の最大メモリ許可サイズ。クエリがユーザー定義のリソースプールで実行されている場合、クエリはこの制限を超えないように保証されます。この場合、クエリに必要な最小メモリがない場合、システムはエラーを発生させます。クエリがシステムプール (既定) で実行されている場合は、少なくとも実行に必要なメモリが取得されます。リソースガバナーの設定がこのヒントで指定された値より小さい場合は、実際の制限を小さくできます。有効な値は 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 Database 以降)。

構成されているメモリ制限の 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の構成オプション 並列処理の最大次数 オーバーライドします。また、このオプションを指定するクエリのリソースガバナーをオーバーライドします。 MAXDOP クエリヒントは、sp_configureで構成された値を超える可能性があります。 MAXDOP リソースガバナーで構成された値を超える場合、データベースエンジンは、ALTER WORKLOAD GROUP で説明されているリソースガバナーの MAXDOP 値使用します。 MAXDOP クエリヒントを使用する場合、最大並列処理 構成オプションで使用されるすべてのセマンティックルールが適用されます。詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。

警告

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

MAXRECURSION <integer_value>

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

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

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

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

NO_PERFORMANCE_SPOOL

:SQL Server (SQL Server 2016 (13.x) 以降) と Azure SQL Database のに適用されます。

スプール演算子がクエリプランに追加されないようにします (有効な更新セマンティクスを保証するために 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 @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 は、プランガイドを作成するときにも役立ちます。

堅牢なプラン

クエリオプティマイザーは、パフォーマンスを犠牲にして、可能な最大行サイズに対して機能するプランを強制的に試します。クエリが処理されるときに、中間テーブルと演算子は、クエリの処理時に入力行の 1 つよりも広い行を格納して処理する必要がある場合があります。行の幅が非常に大きいので、特定の演算子が行を処理できない場合があります。行の幅が広い場合、データベースエンジンはクエリの実行中にエラーを生成します。 ROBUST PLANを使用すると、この問題が発生する可能性のあるクエリプランを考慮しないようにクエリオプティマイザーに指示します。

このようなプランが不可能な場合、クエリオプティマイザーは、クエリの実行に対するエラー検出を遅延するのではなく、エラーを返します。行には可変長列を含めることができます。データベースエンジンを使用すると、データベースエンジンが処理できるサイズを超える最大サイズの行を定義できます。一般に、潜在的な最大サイズにもかかわらず、データベースエンジンが処理できる制限内に実際のサイズを持つ行がアプリケーションに格納されます。データベースエンジンが長すぎる行に遭遇すると、実行エラーが返されます。

USE HINT ( 'hint_name' )

: SQL Server (SQL Server 2016 (13.x) SP1 以降) と Azure SQL Database に適用されます。

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

ヒント

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

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

ヒント	説明
`'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'`	SQL Server 2014 (12.x) 以降のバージョンのクエリオプティマイザーカーディナリティ推定モデルで、結合の既定の基本包含の前提条件ではなく、単純な包含の前提条件を使用してクエリプランを生成します。このヒント名は、トレースフラグ 9476 と同じです。
`'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'`	完全な相関関係を考慮するフィルターの AND 述語を推定するときに、最小限の選択性を使用してプランを生成します。このヒント名は、SQL Server 2012 (11.x) 以前のバージョンのカーディナリティ推定モデルで使用する場合、トレースフラグ 4137 と同じです。また、トレースフラグ 9471 を SQL Server 2014 (12.x) 以降のバージョンのカーディナリティ推定モデルで使用する場合も同様の効果があります。
`'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'`	完全な独立性を考慮するフィルターの AND 述語を推定するときに、最大選択性を使用してプランを生成します。このヒント名は、SQL Server 2012 (11.x) 以前のバージョンのカーディナリティ推定モデルの既定の動作であり、SQL Server 2014 (12.x) 以降のバージョンのカーディナリティ推定モデルで使用される場合、トレースフラグ 9472 に相当します。適用対象: Azure SQL データベース
`'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'`	部分的な相関関係を考慮するフィルターの AND 述語を推定するときに、最も選択性が最も低いプランを生成します。このヒント名は、SQL Server 2014 (12.x) 以降のバージョンのカーディナリティ推定モデルの既定の動作です。適用対象: Azure SQL データベース
`'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'`	クエリプランの生成時に、最適化された入れ子になったループ結合に並べ替え操作 (バッチ並べ替え) を使用しないようにクエリプロセッサに指示します。このヒント名は、トレースフラグ 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 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'`	カーディナリティ推定が必要な先頭のインデックス列に対して、自動的に生成されたクイック統計 (ヒストグラム修正) を有効にします。カーディナリティの推定に使用されるヒストグラムは、クエリのコンパイル時に、この列の実際の最大値または最小値を考慮して調整されます。このヒント名は、トレースフラグ 4139 と同じです。
`'ENABLE_QUERY_OPTIMIZER_HOTFIXES'`	クエリオプティマイザーの修正プログラム (SQL Server 累積的な更新プログラムと Service Pack でリリースされた変更) を有効にします。このヒント名は、トレースフラグ 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 はサポートされているデータベース互換性レベルです。 nで現在サポートされている値の一覧については、sys.dm_exec_valid_use_hintsを参照してください。に適用: SQL Server 2017 (14.x) CU 10 以降のバージョン、および Azure SQL Database
`'QUERY_PLAN_PROFILE'` ²	クエリの軽量プロファイリングを有効にします。この新しいヒントを含むクエリが完了すると、新しい拡張イベント `query_plan_profile`が発生します。この拡張イベントは、`query_post_execution_showplan` 拡張イベントに似た実行統計と実際の実行プラン XML を公開しますが、新しいヒントを含むクエリに対してのみ公開されます。適用対象: SQL Server 2016 (13.x) SP 2 CU 3、SQL Server 2017 (14.x) CU 11 以降のバージョン

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

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

サポートされているすべての 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 テーブルヒントの効果を排除できます。 J の例参照してください。

<table_hint>

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

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

注意事項

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

FOR TIMESTAMP AS OF 'point_in_time'

に適用: Microsoft Fabric Data Warehouse

microsoft Fabric の Synapse Data Warehouse のタイムトラベル機能の一部である、過去に存在していたデータに対してクエリを実行するには、OPTION 句の TIMESTAMP 構文を使用します。

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

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

FORCE [ 単一ノード |分散 ] プラン

に適用: Microsoft Fabric Data Warehouse

ユーザーは、クエリの実行に対して単一ノードプランと分散プランのどちらを強制するかを選択できます。

注釈

ステートメント内で 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 を参照してください。

Fabric Data Warehouse でのクエリヒントのサポート

Microsoft Fabric Data Warehouse では、クエリヒントのサブセットがサポートされています。

HASH GROUP
ORDER GROUP
MERGE UNION
HASH UNION
CONCAT UNION
FORCE ORDER
USE HINT
- ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES
- ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES
- ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES
- ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS

これらのクエリヒントは、Microsoft Fabric Data Warehouse 専用です。

FORCE SINGLE NODE PLAN、FORCE DISTRIBUTED PLAN

例示

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. ハッシュグループと 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 ヒントを使用します。最初の例では、1 つのインデックスを指定します。 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 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);

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

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 で最大メモリ許可サイズをクエリストアで識別される 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 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 のウェアハウス

OPTION 句の TIMESTAMP 構文を使用して、Microsoft Fabric の Synapse Data Warehouse で、過去に存在していたデータに対してクエリを実行します。次のサンプルクエリでは、2024 年 3 月 13 日午後 7:39:35.28 (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

次の方法で共有

クエリ ヒント (Transact-SQL)

構文

議論