テーブルヒント (Transact-SQL)

[アーティクル]
11/19/2024

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

テーブルヒントは、データ操作言語 (DML) ステートメントの実行中、クエリオプティマイザーの既定の動作をオーバーライドするために使用されます。ロック方法、1 つ以上のインデックス、クエリ処理操作 (テーブルスキャンやインデックスシークなど)、その他のオプションを指定できます。テーブルヒントは、DML ステートメントの FROM 句で指定され、その句で参照されるテーブルまたはビューのみに影響します。

注意事項

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

適用対象:

Transact-SQL 構文表記規則

構文

WITH  ( <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
  | SNAPSHOT
  | SPATIAL_WINDOW_MAX_CELLS = <integer_value>
  | TABLOCK
  | TABLOCKX
  | UPDLOCK
  | XLOCK
}

<table_hint_limited> ::=
{
    KEEPIDENTITY
  | KEEPDEFAULTS
  | HOLDLOCK
  | IGNORE_CONSTRAINTS
  | IGNORE_TRIGGERS
  | NOLOCK
  | NOWAIT
  | PAGLOCK
  | READCOMMITTED
  | READCOMMITTEDLOCK
  | READPAST
  | REPEATABLEREAD
  | ROWLOCK
  | SERIALIZABLE
  | SNAPSHOT
  | TABLOCK
  | TABLOCKX
  | UPDLOCK
  | XLOCK
}

引数

WITH ( <table_hint> ) [ [ , ] ...n ]

いくつかの例外を除き、テーブルヒントは、FROM 句で WITH キーワードを使用して指定した場合にのみサポートされます。また、テーブルヒントはかっこを使用して指定する必要があります。

重要

WITH キーワードの省略は非推奨の機能です。この機能は、今後のバージョンの SQL Server で削除される予定です。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

次のテーブルヒントは、WITH キーワードの有無にかかわらず許可されます: NOLOCK、READUNCOMMITTED、UPDLOCK、REPEATABLEREAD、SERIALIZABLE、READCOMMITTED、TABLOCK、TABLOCKX、PAGLOCK、ROWLOCK、NOWAIT、READPAST、XLOCK、SNAPSHOT、および NOEXPAND。 WITH キーワードを使用せずにこれらのテーブルヒントを指定する場合、ヒントは単独で指定する必要があります。次に例を示します。

FROM t (TABLOCK)

ヒントを他のオプションと一緒に指定する場合は、次のように WITH キーワードを使用して指定する必要があります。

FROM t WITH (TABLOCK, INDEX(myindex))

複数のテーブルヒント間にはコンマを使用することをお勧めします。

重要

コンマではなくスペースでヒントを区切ることは非推奨の機能です。この機能は、今後のバージョンの SQL Server で削除される予定です。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

NOEXPAND

クエリオプティマイザーがクエリを処理するときに、基になるテーブルにアクセスするためにインデックス付きビューを展開しないことを指定します。クエリオプティマイザーは、ビューをクラスター化インデックスを持つテーブルのように取り扱います。 NOEXPAND は、インデックス付きビューにのみ適用されます。詳細については、「NOEXPAND の使用」を参照してください。

INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> )

INDEX() 構文では、ステートメントを処理するときにクエリオプティマイザーによって使用される 1 つ以上のインデックスの名前または ID を指定します。一方、INDEX = 構文では、単一のインデックス値を指定します。各テーブルに対して指定できるのは 1 つのインデックスヒントだけです。

クラスター化インデックスがある場合、INDEX(0) はクラスター化インデックスのスキャンを強制し、INDEX(1) はクラスター化インデックスのスキャンまたはシークを強制します。クラスター化インデックスがない場合、INDEX(0) はテーブルスキャンを強制し、INDEX(1) はエラーと見なされます。

1 つのヒントリストの中で複数のインデックスが使用されている場合、重複するものは無視され、一覧表示されている残りのインデックスを使用してテーブルの行が取得されます。インデックスヒント内のインデックスの順番は重要です。複数のインデックスヒントはインデックスの AND 処理も設定し、クエリオプティマイザーはアクセスされる各インデックスに可能な限り多くの条件を適用します。ヒントインデックスのコレクションに、クエリで参照される列のすべてが含まれていない場合、SQL Server データベースエンジンによってすべてのインデックス付き列が取得された後、フェッチを実行して残りの列が取得されます。

Note

複数のインデックスを参照するインデックスヒントが、スター結合のファクトテーブルで使用されている場合、オプティマイザーはそのインデックスヒントを無視し、警告メッセージを返します。また、インデックス論理和は、インデックスヒントが指定されたテーブルでは許可されません。

テーブルヒント内のインデックスの最大個数は、非クラスター化インデックスが 250 個です。

KEEPIDENTITY

OPENROWSET で BULK オプションを使用する場合にのみ、INSERT ステートメントで適用できます。

インポートしたデータファイルの ID 値 (複数可) を ID 列に使用することを指定します。 KEEPIDENTITY を指定しない場合、この列の ID 値は確認されるのみでインポートされません。クエリオプティマイザーでは、テーブルの作成時に指定されたシードおよび増分の値を基に一意な値を自動的に割り当てられます。

重要

テーブルやビューの ID 列の値がデータファイルに含まれておらず、ID 列がテーブルの最終列でもない場合は、その ID 列をスキップする必要があります。詳細については、「フォーマットファイルを使用したデータフィールドのスキップ (SQL Server)」を参照してください。 ID 列のスキップに成功すると、クエリオプティマイザーは、その ID 列の一意な値を、インポートされたテーブル行に自動的に割り当てます。

このヒントを INSERT ... SELECT * FROM OPENROWSET(BULK...) ステートメントに使用する例については、「データの一括インポート時の ID 値の保持 (SQL Server)」を参照してください。

テーブルの ID 値の確認については、「DBCC CHECKIDENT (Transact-SQL)」を参照してください。

KEEPDEFAULTS

OPENROWSET で BULK オプションを使用する場合にのみ、INSERT ステートメントで適用できます。

データレコードにテーブルの列値が含まれていない場合に、NULL の代わりにテーブル列の既定値を挿入することを指定します。

このヒントを INSERT ...SELECT * FROM OPENROWSET(BULK...) ステートメントに使用する例については、「一括インポート中の NULL の保持または既定値の使用 (SQL Server)」を参照してください。

FORCESEEK [ ( <index_value> ( <index_column_name> [ , ...n ] ) ) ]

クエリオプティマイザーで、テーブルまたはビュー内のデータへのアクセスパスとしてインデックスシーク操作のみを使用するように指定します。

注意

SQL Server 2008 R2 (10.50.x) Service Pack 1 以降では、インデックスパラメーターも指定できます。その場合、一度でも指定されたインデックス列が使用されると、クエリオプティマイザーでは指定されたインデックスを介したインデックスのシーク操作のみが検討されます。

index_value

インデックス名またはインデックス ID 値。インデックス ID 0 (ヒープ) は指定できません。インデックスの名前または ID を返すには、sys.indexes カタログビューにクエリを実行します。
index_column_name

シーク操作に含めるインデックス列の名前。インデックスパラメーターと共に FORCESEEK を指定することは、INDEX ヒントと共に FORCESEEK を使用することと同じです。ただし、シーク対象のインデックスとシーク操作で考慮するインデックス列の両方を指定することで、クエリオプティマイザーで使用されるアクセスパスをより詳細に制御できるようになります。オプティマイザーでは、必要に応じて、追加の列が検討される場合もあります。たとえば、非クラスター化インデックスが指定されている場合、オプティマイザーでは、指定された列に加え、クラスター化インデックスのキー列を使用することもできます。

FORCESEEK は以下の方法で指定できます。

構文	例	説明
インデックスまたは `INDEX` ヒントを使用しない場合	`FROM dbo.MyTable WITH (FORCESEEK)`	クエリオプティマイザーでは、関連するインデックスを介してテーブルやビューにアクセスするためのインデックスのシーク操作のみが検討されます。
`INDEX` ヒントと組み合わせた場合	`FROM dbo.MyTable WITH (FORCESEEK, INDEX (MyIndex))`	クエリオプティマイザーでは、指定されたインデックスを介してテーブルやビューにアクセスするためのインデックスのシーク操作のみが検討されます。
インデックスとインデックス列を指定してパラメーター化する場合	`FROM dbo.MyTable WITH (FORCESEEK (MyIndex (col1, col2, col3)))`	少なくとも指定されたインデックス列を使用した場合、クエリオプティマイザーでは、指定されたインデックスを介してテーブルやビューにアクセスするためのインデックスのシーク操作のみが検討されます。

(インデックスパラメーターを使用するかどうかにかかわらず) FORCESEEK ヒントを使用する際は、次のガイドラインを考慮してください。

ヒントは、テーブルヒントまたはクエリヒントとして指定できます。クエリヒントの詳細については、「クエリヒント (Transact-SQL)」を参照してください。
インデックス付きビューに FORCESEEK を適用するには、NOEXPAND ヒントも指定する必要があります。
ヒントは、テーブルまたはビューごとに 1 回だけ適用できます。
このヒントは、リモートデータソースには指定できません。インデックスヒントと共に FORCESEEK を指定すると、エラー 7377 が返されます。また、インデックスヒントなしで FORCESEEK を使用すると、エラー 8180 が返されます。
FORCESEEK が原因でプランが見つからない場合、エラー 8622 が返されます。

インデックスパラメーターと共に FORCESEEK を指定する場合、次のガイドラインと制限が適用されます。

このヒントは、INSERT、UPDATE、または DELETE ステートメントの対象であるテーブルには指定できません。
このヒントを INDEX ヒントまたは別の FORCESEEK ヒントと組み合わせて指定することはできません。
少なくとも 1 列を指定する必要があり、先頭のキー列にする必要があります。
追加のインデックス列を指定できますが、キー列を省略することはできません。たとえば、指定されたインデックスに a、b、および c というキー列が含まれている場合、有効な構文には FORCESEEK (MyIndex (a)) および FORCESEEK (MyIndex (a, b) が含まれます。無効な構文には、FORCESEEK (MyIndex (c)) と FORCESEEK (MyIndex (a, c) が含まれます。
ヒントで指定された列名の順序は、参照先のインデックスでの列の順序と一致させる必要があります。
インデックスキーの定義にない列を指定することはできません。たとえば、非クラスター化インデックスでは、定義されたインデックスキー列のみを指定できます。インデックスに自動的に含まれるクラスター化キー列を指定することはできませんが、オプティマイザーでは使用できます。
xVelocity メモリ最適化列ストアインデックスをインデックスパラメーターとして指定することはできません。エラー 366 が返されます。
インデックス定義を変更すると (列の追加や削除など)、そのインデックスを参照するクエリに対する変更も必要になる場合があります。
ヒントを使用すると、オプティマイザーでは、テーブル上の空間インデックスまたは XML インデックスが検討されなくなります。
このヒントを FORCESCAN ヒントと組み合わせて指定することはできません。
パーティションインデックスの場合、SQL Server によって暗黙的に追加されたパーティション分割列を FORCESEEK ヒントで指定することはできません。

注意事項

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

FORCESCAN

適用対象: SQL Server 2008 R2 (10.50.x) Service Pack 1 以降のバージョン

クエリ・オプティマイザーが、参照されるテーブルまたはビューへのアクセス・パスとしてインデックス・スキャン操作のみを使用することを指定します。 FORCESCAN ヒントは、オプティマイザーが影響を受ける行数を過小評価し、スキャン操作ではなくシーク操作を選択するクエリに役立ちます。この場合、操作に許可されるメモリの量が少なすぎて、クエリのパフォーマンスに影響します。

FORCESCAN を指定する際には、INDEX ヒントを使用してもしなくてもかまいません。インデックスヒント (INDEX = index_name, FORCESCAN) と組み合わせると、クエリオプティマイザーでは、参照されるテーブルにアクセスする際に、指定されたインデックスを介したスキャンアクセスパスのみが考慮されます。 FORCESCANをインデックスヒント INDEX(0) 共に指定すると、ベーステーブルに対するテーブルスキャン操作を強制できます。

パーティションテーブルおよびパーティションインデックスの場合、FORCESCAN は、クエリの述語評価によってパーティションが削除された後に適用されます。つまり、スキャンは、テーブル全体ではなく、残りのパーティションのみに適用されます。

FORCESCAN ヒントには、次の制限があります。

このヒントは、INSERT、UPDATE、または DELETE ステートメントの対象であるテーブルには指定できません。
このヒントを複数のインデックスヒントと共に使用することはできません。
このヒントを使用すると、クエリオプティマイザーで、テーブル上の空間インデックスまたは XML インデックスが考慮されなくなります。
このヒントは、リモートデータソースには指定できません。
このヒントを FORCESEEK ヒントと組み合わせて指定することはできません。

HOLDLOCK

これは、SERIALIZABLE に相当します。詳細については、後の「SERIALIZABLE」を参照してください。 HOLDLOCK は、指定されたテーブルまたはビューに対してのみ、かつ使用されているステートメントによって定義されたトランザクションが実行されている間にのみ適用されます。 HOLDLOCK は、FOR BROWSE オプションを含む SELECT ステートメントでは使用できません。

IGNORE_CONSTRAINTS

OPENROWSET で BULK オプションを使用する場合にのみ、INSERT ステートメントで適用できます。

テーブルに対する制約を一括インポート操作時に無視することを指定します。既定では、INSERT は Unique 制約と CHECK 制約および主キー制約と外部キー制約をチェックします。一括インポート操作の際に IGNORE_CONSTRAINTS を指定している場合、インポート対象のテーブルに対する制約が無視されます。 UNIQUE、PRIMARY KEY、または NOT NULL の各制約を無効にすることはできません。

制約に違反する行が入力データに含まれている場合に、CHECK 制約および FOREIGN KEY 制約を無効化することができます。 CHECK 制約および FOREIGN KEY 制約を無効化することによって、データをインポートしてから、Transact-SQL ステートメントを使用してデータをクリーンアップできます。

ただし、CHECK 制約および FOREIGN KEY 制約を無視すると、操作の後、テーブルに設定されている制約のうち、無視された制約は sys.check_constraints カタログビューまたは sys.foreign_keys カタログビューで is_not_trusted とマークされます。テーブル全体の制約は、任意の時点で必ず検証してください。一括インポート操作の前にテーブルが空白になっていない場合、制約を再検証するコストは、CHECK および FOREIGN KEY 制約を増分データに適用するコストを上回る可能性があります。

IGNORE_TRIGGERS

OPENROWSET で BULK オプションを使用する場合にのみ、INSERT ステートメントで適用できます。

テーブルに対して定義されたトリガーを、一括インポート操作時に無視することを指定します。既定では、INSERT はトリガーを適用します。

IGNORE_TRIGGERS は、アプリケーションがトリガーに依存せず、パフォーマンスの最大化が重要な場合にのみ使用してください。

NOLOCK

これは、READUNCOMMITTED に相当します。詳細については、後の「READUNCOMMITTED」を参照してください。

Note

UPDATE ステートメントまたは DELETE ステートメントの場合: この機能は、今後のバージョンの SQL Server で削除される予定です。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

NOWAIT

テーブルでロックがかかったらすぐにメッセージを返すようにデータベースエンジンを設定します。 NOWAIT は、特定のテーブルに SET LOCK_TIMEOUT 0 を指定することと同じです。 TABLOCK ヒントも含まれている場合、NOWAIT ヒントは機能しません。 TABLOCK ヒントを使用している場合に待機しないでクエリを終了するには、代わりにクエリの前に SET LOCK_TIMEOUT 0; を指定します。

PAGLOCK

通常使用される行やキーに対する個々のロックまたは単一のテーブルロックの代わりに、ページロックを使用します。既定では、操作に適したロックモードを使用します。 SNAPSHOT 分離レベルで動作するトランザクションで PAGLOCK を指定する場合、ロックを必要とする他のテーブルヒント (UPDLOCK や HOLDLOCK など) と組み合わせて指定しない限り、ページロックは取得されません。

READCOMMITTED

読み取り操作が、ロックまたは行のバージョン管理を使用して、READ COMMITTED 分離レベルのルールに従うことを指定します。データベースオプション READ_COMMITTED_SNAPSHOT が OFF の場合、データベースエンジンでは、データの読み取り時に共有ロックを獲得し、読み取り操作が完了するとそれらのロックを解放します。データベースオプション READ_COMMITTED_SNAPSHOT が ON の場合、データベースエンジンでは、ロックを獲得せず、行のバージョン管理を使用します。分離レベルの詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。

Note

READCOMMITTEDLOCK

読み取り操作が、ロックを使用して、READ COMMITTED 分離レベルのルールに従うことを指定します。 READ_COMMITTED_SNAPSHOT データベースオプションの設定にかかわらず、データベースエンジンでは、データの読み取り時に共有ロックを獲得し、読み取り操作が完了するとそれらのロックを解放します。分離の詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。このヒントは、INSERT ステートメントのターゲットテーブルには指定できません。指定すると、エラー 4140 が返されます。

READPAST

他のトランザクションによってロックされている行を、データベースエンジンで読み取らないことを指定します。 READPAST を指定すると、行レベルのロックはスキップされますが、ページレベルのロックはスキップされません。つまり、データベースエンジンは、ロックが解除されるまで現在のトランザクションをブロックする代わりに、行をスキップします。たとえば、テーブル T1 に整数型の列が 1 つあり、値 1、2、3、4、5 が格納されているとします。トランザクション A で値 3 を 8 に変更し、この変更をまだコミットしていない場合、SELECT * FROM T1 (READPAST) によって値 1、2、4、5 が生成されます。 READPAST は主に、SQL Server テーブルを使用する作業キューの実装時に、ロックの競合を減らすために使用されます。 READPAST を使用するキューリーダーは、他のトランザクションによってロックされた過去のキューエントリを次に使用可能なキューエントリにスキップします。他のトランザクションがロックを解放するまで待つ必要はありません。

READPAST は、UPDATE または DELETE ステートメントで参照されるテーブル、および FROM 句で参照されるテーブルに対して指定できます。 UPDATE ステートメントで指定された場合、READPAST は、ステートメントのどこで指定されているかに関係なく、更新するレコードを識別するためにデータを読み取るときにのみ適用されます。 INSERT ステートメントの INTO 句でテーブルに対して READPAST を指定することはできません。更新または削除操作で READPAST を使用すると、外部キーまたはインデックス付きビューの読み取り時、またはセカンダリインデックスの変更時にブロックが発生する場合があります。

READPAST は、READ COMMITTED または REPEATABLE READ 分離レベルで動作するトランザクションでのみ指定できます。 SNAPSHOT 分離レベルで動作するトランザクションで READPAST を指定する場合、ロックを必要とする他のテーブルヒント (UPDLOCK や HOLDLOCK など) と組み合わせて指定する必要があります。

READ_COMMITTED_SNAPSHOT データベースオプションが ON に設定され、次の条件のいずれかに該当する場合、READPAST テーブルヒントを指定することはできません。

セッションのトランザクション分離レベルが READ COMMITTED の場合
クエリで READCOMMITTED テーブルヒントも指定されている。

このような場合に READPAST ヒントを指定するには、READCOMMITTED テーブルヒントがあればそれを削除し、クエリに READCOMMITTEDLOCK テーブルヒントを含めます。

READUNCOMMITTED

ダーティリードを許可することを指定します。現在のトランザクションによって読み取られたデータが、他のトランザクションによって変更されるのを防ぐために、共有ロックは発行されません。また、他のトランザクションによって排他ロックが設定されていても、ロックされたデータを現在のトランザクションで読み取ることはブロックされません。ダーティリードを許可するとコンカレンシーが高まりますが、他のトランザクションによってロールバックされているデータ変更を読み取る可能性があります。この結果、トランザクションでエラーが発生したり、コミットされていないデータがユーザーに提示されたり、レコードが重複表示されたりまったく表示されなかったりする場合があります。

READUNCOMMITTED および NOLOCK ヒントは、データのロックにのみ適用されます。 READUNCOMMITTED および NOLOCK ヒントを含むクエリを含め、すべてのクエリは、コンパイルおよび実行時に Sch-S (スキーマ安定度) ロックを獲得します。このため、同時実行トランザクションがテーブルの Sch-M (スキーマ修正) ロックを保持している場合、クエリはブロックされます。たとえば、データ定義言語 (DDL) 操作では、テーブルのスキーマ情報を変更する前にスキーマ修正 (Sch-M) ロックを取得します。 READUNCOMMITTED または NOLOCK を指定して実行されるクエリを含め、すべての同時クエリは、Sch-S ロックを獲得しようとするとブロックされます。一方、スキーマ安定度 (Sch-S) ロックを保持するクエリによって、スキーマ修正 (Sch-M) ロックを取得しようとする同時実行トランザクションはブロックされます。

挿入、更新、または削除の操作によって変更されたテーブルに対して、READUNCOMMITTED および NOLOCK を指定することはできません。 SQL Server クエリオプティマイザーでは、UPDATE または DELETE ステートメントのターゲットテーブルに適用される FROM 句内の READUNCOMMITTED および NOLOCK ヒントは無視されます。

注意

SQL Server の将来のバージョンでは、UPDATE または DELETE ステートメントのターゲットテーブルに適用される FROM 句での READUNCOMMITTED および NOLOCK ヒントの使用はサポートされなくなる予定です。新しい開発作業ではこのコンテキストでのヒントの使用を避け、現在このヒントを使用しているアプリケーションは変更を検討してください。

次のいずれかを使用することによって、ロックの競合を最小限に抑えながら、コミットされていないデータ変更のダーティリードからトランザクションを保護することができます。

READ COMMITTED 分離レベル (READ_COMMITTED_SNAPSHOT データベースオプションを ON に設定)。
SNAPSHOT 分離レベル。

分離レベルの詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。

Note

READUNCOMMITTED を指定しているときにエラーメッセージ 601 が表示された場合は、デッドロックエラー (エラーメッセージ 1205) の場合と同様に解決し、ステートメントを再試行してください。

REPEATABLEREAD

REPEATABLE READ 分離レベルで実行しているトランザクションと同じロックセマンティクスでスキャンを実行することを指定します。分離レベルの詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。

ROWLOCK

通常取得されるページロックまたはテーブルロックの代わりに、行ロックを取得することを指定します。 SNAPSHOT 分離レベルで動作するトランザクションで ROWLOCK を指定する場合、ロックを必要とする他のテーブルヒント (UPDLOCK や HOLDLOCK など) と組み合わせて指定しない限り、行ロックは取得されません。クラスター化された列ストアインデックスのあるテーブルでは、ROWLOCK を使用することはできません。次の例では、アプリケーションにエラー 651 が返されます。

UPDATE [dbo].[FactResellerSalesXL_CCI] WITH (ROWLOCK)
SET UnitPrice = 50
WHERE ProductKey = 150;

SERIALIZABLE

これは、HOLDLOCK に相当します。共有ロックがより制限的になります。テーブルまたはデータページが不要になったときに、トランザクションが完了しているかどうかにかかわらず共有ロックが解除されるのではなく、共有ロックはトランザクションが完了するまで保持されます。スキャンは、SERIALIZABLE 分離レベルで実行されるトランザクションと同じセマンティクスで実行されます。分離レベルの詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。

SNAPSHOT

適用対象: SQL Server 2014 (12.x) 以降のバージョン

メモリ最適化されたテーブルは、SNAPSHOT 分離でアクセスされます。次の例で示すように、SNAPSHOT は、メモリ最適化テーブルのみで使用できます (ディスクベースのテーブルでは使用できません)。詳細については、「メモリ最適化テーブルの概要」を参照してください。

SELECT *
FROM dbo.Customers AS c WITH (SNAPSHOT)
LEFT JOIN dbo.[Order History] AS oh
    ON c.customer_id=oh.customer_id;

SPATIAL_WINDOW_MAX_CELLS = <integer_value>

適用対象: SQL Server 2012 (11.x) 以降のバージョン

geometry オブジェクトや geography オブジェクトのテセレーションに使用するセルの最大数を指定します。 <integer_value> は、1 - 8192 の整数値です。

このオプションを使用すると、プライマリとセカンダリのフィルターの実行時間の間のトレードオフを調整することによって、クエリの実行時間を微調整できます。値を大きくすると、セカンダリフィルターの実行時間が短縮されますが、プライマリフィルターの実行時間が増加します。値を小さくすると、プライマリフィルターの実行時間が短縮されますが、セカンダリフィルターの実行時間が増加します。密度の高い空間データの場合は、大きい値を指定して、プライマリフィルターでより適切な近似値を提供し、セカンダリフィルターの実行時間を減少させることで、実行時間を短縮させます。密度の低いデータの場合は、小さい値を指定して、プライマリフィルターの実行時間を短縮します。

このオプションは、手動と自動の両方のグリッドテセレーションに使用できます。

TABLOCK

取得したロックがテーブルレベルで適用されることを指定します。取得されるロックの種類は、実行されるステートメントによって異なります。たとえば、SELECT ステートメントを実行すると、共有ロックが取得されます。 TABLOCK を指定することで、共有ロックが、行またはページレベルではなくテーブル全体に適用されます。 HOLDLOCK も指定されている場合、テーブルロックはトランザクションが終了するまで保持されます。

INSERT INTO <target_table> SELECT <columns> FROM <source_table> ステートメントを使用してデータをヒープにインポートする場合、ターゲットテーブルに対して TABLOCK ヒントを指定すると、そのステートメントに対して最小限のログと最適なロックを有効にすることができます。データベース復旧モデルが単純復旧モデルまたは一括ログ復旧モデルに設定されている必要もあります。 TABLOCK ヒントを使用すると、ヒープまたはクラスター化列ストアインデックスに対する並列挿入も有効になります。詳細については、「INSERT (Transact-SQL)」を参照してください。

テーブルにデータをインポートするため、OPENROWSET 一括行セットプロバイダーで TABLOCK を使用すると、ログとロックを最適化して、ターゲットテーブルへのデータの読み込みを複数のクライアントで同時に行うことができます。詳細については、「一括インポートで最小ログ記録を行うための前提条件」次を参照してください。

TABLOCKX

テーブルに排他ロックを使用することを指定します。

UPDLOCK

更新ロックを使用することと、これをトランザクション終了まで保持することを指定します。 UPDLOCK を使用すると、行レベルまたはページレベルの読み取り操作に対してのみ更新ロックが適用されます。 UPDLOCK を TABLOCK と組み合わせるか、なんらかの理由でテーブルレベルのロックを取得すると、代わりに排他 (X) ロックが取得されます。

UPDLOCK を指定すると、READCOMMITTED および READCOMMITTEDLOCK 分離レベルのヒントは無視されます。たとえば、セッションの分離レベルを SERIALIZABLE に設定し、クエリで (UPDLOCK、READCOMMITTED) を指定すると、READCOMMITTED ヒントは無視され、トランザクションは SERIALIZABLE 分離レベルを使用して実行されます。

XLOCK

排他ロックを使用することと、これをトランザクション終了まで保持することを指定します。 ROWLOCK、PAGLOCK、または TABLOCK と組み合わせて指定すると、排他ロックは適切な粒度レベルに適用されます。

注釈

テーブルがクエリプランによってアクセスされない場合、テーブルヒントは無視されます。これは、オプティマイザーがテーブルにまったくアクセスしないことを選択した結果であるか、またはインデックス付きビューが代わりにアクセスされるためである可能性があります。後者の場合、OPTION (EXPAND VIEWS) クエリヒントを使用することで、インデックス付きビューへのアクセスを防ぐことができます。

すべてのロックヒントが、クエリプランによってアクセスされているすべてのテーブルおよびビュー (ビューで参照されているテーブルおよびビューを含む) に反映されます。また、SQL Server は、対応するロックの整合性チェックを実行します。

行レベルのロックを獲得するロックヒント ROWLOCK、UPDLOCK、XLOCK では、実際のデータ行ではなくインデックスキーに対してロックが実行される場合があります。たとえば、テーブルに非クラスター化インデックスがあり、ロックヒントを使用する SELECT ステートメントがカバーするインデックスによって処理される場合、ベーステーブルのデータ行ではなく、カバーするインデックスのインデックスキーに対してロックが取得されます。

テーブルに計算列が含まれており、その計算列が、別のテーブル内の列にアクセスする式または関数によって計算される場合、テーブルヒントがそれらのテーブルで使用されたり、反映されたりすることはありません。たとえば、クエリ内のテーブルに NOLOCK テーブルヒントが指定されているものとします。このテーブルには、別のテーブル内の列にアクセスする式と関数の組み合わせで計算される、計算列があります。式と関数で参照されるテーブルでは、アクセスされるときに NOLOCK テーブルヒントが使用されることはありません。

SQL Server では、FROM 句内の各テーブルに対して、次の各グループの複数のテーブルヒントを使用することはできません。

粒度ヒント: PAGLOCK、NOLOCK、READCOMMITTEDLOCK、ROWLOCK、TABLOCK、TABLOCKX。
分離レベルヒント: HOLDLOCK、NOLOCK、READCOMMITTED、REPEATABLEREAD、SERIALIZABLE。

フィルター選択されたインデックスヒント

フィルター選択されたインデックスをテーブルヒントとして使用できますが、クエリで選択される行がすべて対象ではない場合、クエリオプティマイザーによってエラー 8622 が生成されます。フィルター選択されたインデックスヒントが無効になる例を次に示します。この例では、フィルター選択されたインデックス FIBillOfMaterialsWithComponentID を作成し、SELECT ステートメントのインデックスヒントとして使用します。フィルター選択されたインデックスの述語には、ComponentID が 533、324、および 753 のデータ行が含まれています。クエリ述語にも ComponentID が 533、324、753 のデータ行が含まれていますが、ComponentID 855 および 924 も含めるように結果セットが拡張されています。これらは、フィルター選択されたインデックスには含まれていません。したがって、クエリオプティマイザーは、フィルター選択されたインデックスヒントを使用できず、エラー 8622 が生成されます。詳細については、「 Create Filtered Indexes」を参照してください。

IF EXISTS (SELECT name FROM sys.indexes
    WHERE name = N'FIBillOfMaterialsWithComponentID'
    AND object_id = OBJECT_ID(N'Production.BillOfMaterials'))
DROP INDEX FIBillOfMaterialsWithComponentID
    ON Production.BillOfMaterials;
GO
CREATE NONCLUSTERED INDEX "FIBillOfMaterialsWithComponentID"
    ON Production.BillOfMaterials (ComponentID, StartDate, EndDate)
    WHERE ComponentID IN (533, 324, 753);
GO
SELECT StartDate, ComponentID FROM Production.BillOfMaterials
    WITH(INDEX (FIBillOfMaterialsWithComponentID))
    WHERE ComponentID in (533, 324, 753, 855, 924);
GO

SET オプションに、フィルター選択されたインデックスに必要な値がない場合、クエリオプティマイザーではインデックスヒントが考慮されません。詳細については、「 CREATE INDEX (Transact-SQL)」を参照してください。

NOEXPAND を使用する

NOEXPAND は、"インデックス付きビュー" にのみ適用されます。インデックス付きビューとは、一意なクラスター化インデックスが作成されているビューを示します。インデックス付きビューおよびベーステーブルの両方に存在する列への参照がクエリに含まれていて、クエリオプティマイザーがクエリの実行にインデックス付きビューを使用する方が最適であると判断した場合、クエリオプティマイザーはビューのインデックスを利用します。この機能は、インデックス付きビューのマッチングと呼ばれます。 SQL Server 2016 (13.x) Service Pack 1 より前のバージョンでは、SQL Server の特定のエディションでのみ、クエリオプティマイザーによるインデックス付きビューの自動的な使用がサポートされています。すべてのエディションでは、インデックス付きビューの自動使用がサポートされているためです。また、Azure SQL Database および Azure SQL Managed Instance では、NOEXPAND ヒントを指定しなくても、インデックス付きビューの自動的な使用もサポートされます。

詳細については、「クエリ処理アーキテクチャガイド」を参照してください。

Windows の SQL Server の各エディションでサポートされる機能の一覧については、以下を参照してください。

ただし、クエリオプティマイザーで、インデックス付きビューのマッチングを考慮したり、NOEXPAND ヒントで参照されるインデックス付きビューを使用したりするには、以下の SET オプションを ON に設定する必要があります。

ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT ¹
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER

¹ ARITHABORT は、ANSI_WARNINGS が ON に設定されている場合は、暗黙的に ON に設定されます。したがって、この設定を手動で調整する必要はありません。

また、NUMERIC_ROUNDABORT オプションは OFF に設定する必要があります。

クエリオプティマイザーでインデックス付きビューのインデックスを使用するように強制するには、NOEXPAND オプションを指定します。このヒントは、ビューがクエリ内でも指定されている場合にのみ使用できます。 SQL Server では、FROM 句で直接ビュー名を指定していないクエリで、特定のインデックス付きビューが使用されるようにするヒントは用意されていません。しかし、クエリオプティマイザーでは、インデックス付きビューがクエリで直接参照されていなくても、その使用が考慮されます。 NOEXPAND テーブルヒントを使用すると、SQL Server データベースエンジンでは、インデックス付きビューに関してのみ自動的に統計が作成されます。このヒントを省略すると、統計の不足に関する実行プランの警告が発生する可能性があります。これは、統計を手動で作成しても解決することはできません。

クエリの最適化中、データベースエンジンでは、クエリでビューが直接参照されたり、NOEXPAND ヒントが使用されたりするときに、自動的に、または手動で作成されたビュー統計を使用します。

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

OPTION (TABLE HINT) 句を使用すると、テーブルヒントをクエリヒントとして指定することもできます。プランガイドのコンテキスト内でのみ、テーブルヒントをクエリヒントとして使用することをお勧めします。アドホッククエリに対しては、これらのヒントをテーブルヒントとしてのみ指定します。詳細については、「クエリヒント (Transact-SQL)」を参照してください。

アクセス許可

KEEPIDENTITY、IGNORE_CONSTRAINTS、IGNORE_TRIGGERS の各ヒントには、テーブルに対する ALTER 権限が必要です。

例

A. TABLOCK ヒントを使用してロック手法を指定する

次の例では、AdventureWorks2022 データベースの Production.Product テーブルに対する共有ロックを取得し、UPDATE ステートメントの終了まで保持することを指定します。

UPDATE Production.Product
WITH (TABLOCK)
SET ListPrice = ListPrice * 1.10
WHERE ProductNumber LIKE 'BK-%';
GO

B. FORCESEEK ヒントを使用してインデックスシーク操作を指定する

次の例では、インデックスを指定せずに FORCESEEK ヒントを使用して、クエリオプティマイザーで AdventureWorks2022 データベースの Sales.SalesOrderDetail テーブルに対するインデックスシーク操作を実行するように強制します。

SELECT *
FROM Sales.SalesOrderHeader AS h
INNER JOIN Sales.SalesOrderDetail AS d WITH (FORCESEEK)
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.TotalDue > 100
AND (d.OrderQty > 5 OR d.LineTotal < 1000.00);
GO

次の例では、インデックスと共に FORCESEEK ヒントを使用して、クエリオプティマイザーで、指定したインデックスおよびインデックス列に対してインデックスシーク操作を実行するように強制します。

SELECT h.SalesOrderID, h.TotalDue, d.OrderQty
FROM Sales.SalesOrderHeader AS h
    INNER JOIN Sales.SalesOrderDetail AS d
    WITH (FORCESEEK (PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID (SalesOrderID)))
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.TotalDue > 100
AND (d.OrderQty > 5 OR d.LineTotal < 1000.00);
GO

C. FORCESCAN ヒントを使用してインデックススキャン操作を指定する

次の例では、FORCESCAN ヒントを使って、AdventureWorks2022 データベースの Sales.SalesOrderDetail テーブルにスキャン操作を実行するようクエリオプティマイザーに強制します。

SELECT h.SalesOrderID, h.TotalDue, d.OrderQty
FROM Sales.SalesOrderHeader AS h
    INNER JOIN Sales.SalesOrderDetail AS d
    WITH (FORCESCAN)
    ON h.SalesOrderID = d.SalesOrderID
WHERE h.TotalDue > 100
AND (d.OrderQty > 5 OR d.LineTotal < 1000.00);

次の方法で共有

テーブル ヒント (Transact-SQL)

構文

引数

WITH ( <table_hint> ) [ [ , ] ...n ]

NOEXPAND

INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> )

KEEPIDENTITY

KEEPDEFAULTS

FORCESEEK [ ( <index_value> ( <index_column_name> [ , ...n ] ) ) ]

FORCESCAN

HOLDLOCK

IGNORE_CONSTRAINTS

IGNORE_TRIGGERS

NOLOCK

NOWAIT

PAGLOCK

READCOMMITTED

READCOMMITTEDLOCK

READPAST

READUNCOMMITTED

REPEATABLEREAD

ROWLOCK

SERIALIZABLE

SNAPSHOT

SPATIAL_WINDOW_MAX_CELLS = <integer_value>

TABLOCK

TABLOCKX

UPDLOCK

XLOCK

注釈

フィルター選択されたインデックス ヒント

NOEXPAND を使用する

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

アクセス許可

例

A. TABLOCK ヒントを使用してロック手法を指定する

B. FORCESEEK ヒントを使用してインデックス シーク操作を指定する

C. FORCESCAN ヒントを使用してインデックス スキャン操作を指定する

関連するコンテンツ

フィードバック

その他のリソース

テーブルヒント (Transact-SQL)

フィルター選択されたインデックスヒント

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

B. FORCESEEK ヒントを使用してインデックスシーク操作を指定する

C. FORCESCAN ヒントを使用してインデックススキャン操作を指定する