クエリヒント (Transact-SQL)

[アーティクル]
10/31/2013

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

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

適用対象

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

構文

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

<table_hint> ::=
[ NOEXPAND ] { 
    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 
  | SPATIAL_WINDOW_MAX_CELLS = integer
  | TABLOCK 
  | TABLOCKX 
  | UPDLOCK 
  | XLOCK
}

引数

{ 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)」を参照してください。
EXPAND VIEWS
インデックス付きビューが展開されていることを指定します。これによって、クエリオプティマイザーがインデックス付きビューをクエリの一部の代わりであると見なすことがなくなります。ビューが展開されるのは、ビュー名がクエリテキスト内のビュー定義に置換される場合です。

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

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

INSERT、UPDATE、MERGE、DELETE ステートメントなど、ステートメントの SELECT 要素内のビューのみが、ヒントの影響を受けます。
FAST number_rows
最初の number_rows を高速検索するためにクエリの最適化を行うことを指定します。これは、負以外の整数です。最初の number_rows を返した後、クエリは実行を続け、完全な結果セットを作成します。

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

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

KEEP PLAN
クエリオプティマイザーに対して、クエリに推定される再コンパイルしきい値を緩和することを指定します。推定される再コンパイルしきい値とは、UPDATE、DELETE、MERGE、または INSERT ステートメントの実行により、予測した回数のインデックス列変更がテーブルに加えられた場合に、クエリを自動的に再コンパイルする時点のことです。 KEEP PLAN を指定することによって、テーブルに複数の更新が加えられても、クエリは頻繁に再コンパイルされません。
KEEPFIXED PLAN
統計情報の変更に応じてクエリを再コンパイルしないようにクエリオプティマイザーを設定します。 KEEPFIXED PLAN を指定することによって、クエリの基になるテーブルのスキーマが変更された場合、またはそのテーブルに対して sp_recompile が実行された場合のみ、クエリが再コンパイルされます。
IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX
クエリで非クラスター化 xVelocity メモリ最適化列ストアインデックスが使用されないようにします。クエリに、列ストアインデックスの使用を回避するクエリヒントと、列ストアインデックスを使用するためのインデックスヒントがある場合、ヒントが競合してクエリはエラーを返します。
MAXDOP number
このオプションを指定しているクエリに対して、sp_configure およびリソースガバナーの max degree of parallelism 構成オプションを上書きします。 MAXDOP クエリヒントは、sp_configure で構成されている値を超えて指定できます。 MAXDOP の値がリソースガバナーで構成されている値を超える場合は、「ALTER WORKLOAD GROUP (Transact-SQL)」で説明されているように、データベースエンジンでリソースガバナーの MAXDOP 値が使用されます。 MAXDOP クエリヒントを使用している場合は、max degree of parallelism 構成オプションで使用されるすべての意味ルールを適用できます。詳細については、「max degree of parallelism サーバー構成オプションの構成」を参照してください。

注意

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

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

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

詳細については、「WITH common_table_expression (Transact-SQL)」を参照してください。
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 UNKNOWN
クエリオプティマイザーでクエリをコンパイルおよび最適化するときに、強制パラメーター化によって作成されたパラメーターも含め、すべてのローカル変数に対して初期値の代わりに統計データを使用することを指定します。

同一のクエリヒント内で OPTIMIZE FOR @variable\_name = literal_constant と OPTIMIZE FOR UNKNOWN が使用されている場合、クエリオプティマイザーでは、特定の値に対しては指定された literal_constant を使用し、残りの変数値には UNKNOWN を使用します。これらの値はクエリを最適化する過程でのみ使用され、クエリの実行時には使用されません。
PARAMETERIZATION { SIMPLE | FORCED }
クエリのコンパイル時に SQL Server クエリオプティマイザーがそのクエリに適用するパラメーター化のルールを指定します。

重要

PARAMETERIZATION クエリヒントはプランガイド内部でのみ指定できます。クエリの中で直接指定することはできません。

SIMPLE は、クエリオプティマイザーに対して簡易パラメーター化を試行するように指示します。 FORCED は、オプティマイザーに対して強制パラメーター化を試行するように指示します。 PARAMETERIZATION クエリヒントは、プランガイド内部の PARAMETERIZATION データベース SET オプションの現在の設定を上書きするのに使用します。詳細については、「プランガイドを使用したクエリのパラメーター化動作の指定」を参照してください。
RECOMPILE
クエリの実行後、そのクエリに対して生成されたプランを破棄し、次回同じクエリが実行されたときにクエリオプティマイザーにクエリプランを再コンパイルさせるよう SQL Server データベースエンジンに指示します。 RECOMPILE を指定しない場合、データベースエンジンはクエリプランをキャッシュして再利用します。クエリプランをコンパイルする場合、RECOMPILE クエリヒントは、クエリ内のローカル変数の現在値を使用し、クエリがストアドプロシージャ内にある場合は任意のパラメーターに渡された現在値を使用します。

RECOMPILE は、ストアドプロシージャ全体ではなくその中のクエリのサブセットだけを再コンパイルする必要がある場合に、WITH RECOMPILE 句を使用したストアドプロシージャを作成する代わりに使用すると便利です。詳細については、「ストアドプロシージャの再コンパイル」を参照してください。 RECOMPILE はプランガイドを作成するときにも利用できます。
ROBUST PLAN
クエリオプティマイザーで、最大許容行サイズで動作するプランを試行するよう設定します。ただし、この場合は性能が低下する可能性があります。クエリの処理の際、中間テーブルや演算子が入力行よりも大きな行を格納し、処理しなければならない可能性があります。行があまりに大きいと、演算子によっては行を処理できない場合もあります。このような状態が発生すると、クエリの実行中にデータベースエンジンからエラーが出力されます。 ROBUST PLAN を使用することで、クエリオプティマイザーに対して、このような問題を発生するクエリプランを考慮しないことを指示します。

このようなプランが可能でない場合は、クエリ実行の後でエラー検出を行うのではなく、クエリオプティマイザーがエラーを返します。行は可変長列で構成されている可能性があります。データベースエンジンでは、データベースエンジンが処理できる範囲を超えた最大可能サイズを持つように、行を定義できます。通常、可能な最大サイズに関係なく、アプリケーションはデータベースエンジンの処理能力で実際に対応できるサイズの行を格納します。データベースエンジンが長すぎる行を検出した場合は、実行エラーが返されます。
USE PLAN N**'xml_plan'**
'xml_plan' で指定されているクエリの既存のクエリプランを使用するように、クエリオプティマイザーを設定します。 USE PLAN は、INSERT、UPDATE、MERGE、または DELETE の各ステートメントに指定することはできません。
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 を参照してください。

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

重要
PARAMETERIZATION クエリヒントはプランガイド内部でのみ指定できます。クエリの中で直接指定することはできません。

<table_hint> ::= { [ NOEXPAND ] { 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 |SPATIAL_WINDOW_MAX_CELLS | TABLOCK | TABLOCKX | UPDLOCK | XLOCK }
exposed_object_name に対応するテーブルまたはビューにクエリヒントとして適用するテーブルヒントを指定します。これらのヒントの説明については、「テーブルヒント (Transact-SQL)」を参照してください。

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

注意
パラメーターを使用して FORCESEEK を指定すると、オプティマイザーで考慮できるプラン数の制限は、パラメーターなしで FORCESEEK を指定した場合よりも多くなります。これにより、"プランを生成できない" というエラーが生じる回数が増加する可能性があります。将来のリリースでは、オプティマイザーに対して内部変更を行うため、より多くのプランを考慮できるようになります。

パラメーターを使用して FORCESEEK を指定すると、オプティマイザーで考慮できるプラン数の制限は、パラメーターなしで FORCESEEK を指定した場合よりも多くなります。これにより、"プランを生成できない" というエラーが生じる回数が増加する可能性があります。将来のリリースでは、オプティマイザーに対して内部変更を行うため、より多くのプランを考慮できるようになります。

説明

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

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

クエリヒントとしてのテーブルヒントの指定

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

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

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

INDEX、FORCESCAN、および FORCESEEK テーブルヒントは、既存のテーブルヒントを持たないクエリのクエリヒントとして指定できます。また、それぞれ、クエリ内の既存の INDEX、FORCESCAN、または FORCESEEK ヒントの代わりに使用することもできます。 INDEX、FORCESCAN、および FORCESEEK 以外のテーブルヒントは、クエリで既に WITH 句を使用してテーブルヒントが指定されていない限り、クエリヒントとして使用できません。この場合に、そのクエリのセマンティックを維持するには、OPTION 句で TABLE HINT を使用して、対応するヒントもクエリヒントとして指定する必要があります。たとえば、クエリにテーブルヒント NOLOCK が含まれている場合、プランガイドの @hints パラメーターの OPTION 句にも NOLOCK ヒントが含まれている必要があります。例 K を参照してください。 INDEX、FORCESCAN、または FORCESEEK 以外のテーブルヒントが OPTION 句で TABLE HINT を使用して指定されている一方で対応するクエリヒントがない場合 (またはその逆の場合)、OPTION 句によりクエリのセマンティックが変更されることを示すエラー 8702 が発生し、クエリが失敗します。

使用例

A. MERGE JOIN を使用する

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

USE AdventureWorks2012;
GO
SELECT * 
FROM Sales.Customer AS c
INNER JOIN Sales.vStoreWithAddresses AS sa 
    ON c.CustomerID = sa.BusinessEntityID
WHERE TerritoryID = 5
OPTION (MERGE JOIN);
GO

B. OPTIMIZE FOR を使用する

次の例では、クエリオプティマイザーでのクエリの最適化時に、ローカル変数 @city\_name に値 'Seattle' を使用し、統計データを使用してローカル変数 @postal\_code の値を決定するように指定しています。

USE AdventureWorks2012;
GO
DECLARE @city_name nvarchar(30);
DECLARE @postal_code nvarchar(15);
SET @city_name = 'Ascheim';
SET @postal_code = 86171;
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 に制限しています。

USE AdventureWorks2012;
GO
--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 クエリヒントを使用します。

USE AdventureWorks2012;
GO
SELECT BusinessEntityID, JobTitle, HireDate, VacationHours, SickLeaveHours
FROM HumanResources.Employee AS e1
UNION
SELECT BusinessEntityID, JobTitle, HireDate, VacationHours, SickLeaveHours
FROM HumanResources.Employee AS e2
OPTION (MERGE UNION);
GO

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

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

USE AdventureWorks2012;
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 AdventureWorks2012 ;
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

G. INDEX を使用する

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

USE AdventureWorks2012;
GO
EXEC sp_create_plan_guide 
    @name = N'Guide1', 
    @stmt = N'SELECT c.LastName, c.FirstName, e.JobTitle
              FROM HumanResources.Employee AS e 
              JOIN Person.Person AS c ON e.BusinessEntityID = c.BusinessEntityID
              WHERE e.OrganizationLevel = 2;', 
    @type = N'SQL',
    @module_or_batch = NULL, 
    @params = NULL, 
    @hints = N'OPTION (TABLE HINT(e, INDEX (IX_Employee_OrganizationLevel_OrganizationNode)))';
GO
EXEC sp_create_plan_guide 
    @name = N'Guide2', 
    @stmt = N'SELECT c.LastName, c.FirstName, e.JobTitle
              FROM HumanResources.Employee AS e 
              JOIN Person.Person AS c ON e.BusinessEntityID = c.BusinessEntityID
              WHERE e.OrganizationLevel = 2;', 
    @type = N'SQL',
    @module_or_batch = NULL, 
    @params = NULL, 
    @hints = N'OPTION (TABLE HINT(e, INDEX(PK_Employee_BusinessEntityID, IX_Employee_OrganizationLevel_OrganizationNode)))';
GO

H. FORCESEEK を使用する

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

USE AdventureWorks2012;
GO
EXEC sp_create_plan_guide 
    @name = N'Guide3', 
    @stmt = N'SELECT c.LastName, c.FirstName, HumanResources.Employee.JobTitle
              FROM HumanResources.Employee
              JOIN Person.Person AS c ON HumanResources.Employee.BusinessEntityID = c.BusinessEntityID
              WHERE HumanResources.Employee.OrganizationLevel = 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 ヒントをそれぞれ別のテーブルに適用します。

USE AdventureWorks2012;
GO
EXEC sp_create_plan_guide 
    @name = N'Guide4', 
    @stmt = N'SELECT c.LastName, c.FirstName, e.JobTitle
              FROM HumanResources.Employee AS e 
              JOIN Person.Person AS c ON e.BusinessEntityID = c.BusinessEntityID
              WHERE OrganizationLevel = 3;', 
    @type = N'SQL',
    @module_or_batch = NULL, 
    @params = NULL, 
    @hints = N'OPTION (TABLE HINT ( e, INDEX( IX_Employee_OrganizationLevel_OrganizationNode ) ) 
                       , TABLE HINT ( c, FORCESEEK) )';
GO

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

次の例では、ヒントを指定しないで TABLE HINT ヒントを使用して、クエリの FROM 句に指定されている INDEX テーブルヒントの動作をオーバーライドする方法を示します。

USE AdventureWorks2012;
GO
EXEC sp_create_plan_guide 
    @name = N'Guide5', 
    @stmt = N'SELECT c.LastName, c.FirstName, e.JobTitle
              FROM HumanResources.Employee AS e WITH (INDEX (IX_Employee_OrganizationLevel_OrganizationNode))
              JOIN Person.Person AS c ON e.BusinessEntityID = c.BusinessEntityID
              WHERE OrganizationLevel = 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 ヒントが置き換えられます。

USE AdventureWorks2012;
GO
EXEC sp_create_plan_guide 
    @name = N'Guide6', 
    @stmt = N'SELECT c.LastName, c.FirstName, e.JobTitle
              FROM HumanResources.Employee AS e 
              JOIN Person.Person AS c ON e.BusinessEntityID = c.BusinessEntityID
              WHERE OrganizationLevel = 3;',
    @type = N'SQL',
    @module_or_batch = NULL, 
    @params = NULL, 
    @hints = N'OPTION (TABLE HINT ( e, INDEX( IX_Employee_OrganizationLevel_OrganizationNode) , NOLOCK, FORCESEEK ))';
GO

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

USE AdventureWorks2012;
GO
EXEC sp_create_plan_guide 
    @name = N'Guide7', 
    @stmt = N'SELECT c.LastName, c.FirstName, e.JobTitle
              FROM HumanResources.Employee AS e 
              JOIN Person.Person AS c ON e.BusinessEntityID = c.BusinessEntityID
              WHERE OrganizationLevel = 2;',
    @type = N'SQL',
    @module_or_batch = NULL, 
    @params = NULL, 
    @hints = N'OPTION (TABLE HINT ( e, NOLOCK))';
GO

次の方法で共有

クエリヒント (Transact-SQL)

構文

引数

説明

クエリヒントとしてのテーブルヒントの指定

使用例

A. MERGE JOIN を使用する

B. OPTIMIZE FOR を使用する

C. MAXRECURSION を使用する

D. MERGE UNION を使用する

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

F. MAXDOP を使用する

G. INDEX を使用する

H. FORCESEEK を使用する

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

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

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

関連項目

参照

その他のリソース

次の方法で共有

クエリ ヒント (Transact-SQL)

構文

引数

説明

クエリ ヒントとしてのテーブル ヒントの指定

使用例

A. MERGE JOIN を使用する

B. OPTIMIZE FOR を使用する

C. MAXRECURSION を使用する

D. MERGE UNION を使用する

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

F. MAXDOP を使用する

G. INDEX を使用する

H. FORCESEEK を使用する

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

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

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

関連項目

参照

その他のリソース

クエリヒント (Transact-SQL)

クエリヒントとしてのテーブルヒントの指定

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

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

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