ヒント (Transact-SQL) - TableHints (Transact-SQL) - Table

適用対象: ○SQL Server (2008 以降) ○Azure SQL Database XAzure SQL Data Warehouse XParallel Data Warehouse APPLIES TO: yesSQL Server (starting with 2008) yesAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

テーブル ヒントでは、ロック手法、1 つ以上のインデックス、クエリ処理操作 (テーブル スキャンやインデックスのシークなど)、またはその他のオプションを指定することによって、データ操作言語 (DML) ステートメントが存続する間だけ、クエリ オプティマイザーの既定の動作をオーバーライドします。Table hints override the default behavior of the query optimizer for the duration of the data manipulation language (DML) statement by specifying a locking method, one or more indexes, a query-processing operation such as a table scan or index seek, or other options. テーブル ヒントは、DML ステートメントの FROM 句で指定され、その句で参照されるテーブルまたはビューのみに影響します。Table hints are specified in the FROM clause of the DML statement and affect only the table or view referenced in that clause.

注意事項

通常、SQL ServerSQL Server クエリ オプティマイザーでは、クエリにとって最適な実行プランが選択されるため、ヒントは、経験を積んだ開発者やデータベース管理者が最後の手段としてのみ使用することをお勧めします。Because the SQL ServerSQL Server query optimizer typically selects the best execution plan for a query, we recommend that hints be used only as a last resort by experienced developers and database administrators.

適用対象:Applies to:

DELETEDELETE

INSERTINSERT

SELECTSELECT

UPDATEUPDATE

MERGEMERGE

トピック リンク アイコン Transact-SQL 構文表記規則Topic link icon Transact-SQL Syntax Conventions

構文Syntax

WITH  ( <table_hint> [ [, ]...n ] )  
  
<table_hint> ::=   
[ NOEXPAND ] {   
    INDEX  ( index_value [ ,...n ] )   
  | INDEX =  ( index_value )      
  | FORCESEEK [( index_value ( index_column_name  [ ,... ] ) ) ]  
  | FORCESCAN  
  | FORCESEEK  
  | HOLDLOCK   
  | NOLOCK   
  | NOWAIT  
  | PAGLOCK   
  | READCOMMITTED   
  | READCOMMITTEDLOCK   
  | READPAST   
  | READUNCOMMITTED   
  | REPEATABLEREAD   
  | ROWLOCK   
  | SERIALIZABLE   
  | SNAPSHOT   
  | SPATIAL_WINDOW_MAX_CELLS = integer  
  | 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   
}   

引数Arguments

WITH ( <table_hint> ) [,]...n ]WITH ( <table_hint> ) [ [, ]...n ]
いくつかの例外を除き、テーブル ヒントは、FROM 句で WITH キーワードを使用して指定した場合にのみサポートされます。With some exceptions, table hints are supported in the FROM clause only when the hints are specified with the WITH keyword. また、テーブル ヒントはかっこを使用して指定する必要があります。Table hints also must be specified with parentheses.

重要

WITH キーワードを省略することは非推奨とされます。この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature.Omitting the WITH keyword is a deprecated feature: この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

次のテーブル ヒントは、WITH キーワードを付けても付けなくても使用できます。NOLOCK、READUNCOMMITTED、UPDLOCK、REPEATABLEREAD、SERIALIZABLE、READCOMMITTED、TABLOCK、TABLOCKX、PAGLOCK、ROWLOCK、NOWAIT、READPAST、XLOCK、SNAPSHOT、および NOEXPAND。The following table hints are allowed with and without the WITH keyword: NOLOCK, READUNCOMMITTED, UPDLOCK, REPEATABLEREAD, SERIALIZABLE, READCOMMITTED, TABLOCK, TABLOCKX, PAGLOCK, ROWLOCK, NOWAIT, READPAST, XLOCK, SNAPSHOT, and NOEXPAND. これらのテーブル ヒントを WITH キーワードを使用せずに指定するときは、単独で指定してください。When these table hints are specified without the WITH keyword, the hints should be specified alone. 例 :For example:

FROM t (TABLOCK)  

ヒントを他のオプションと一緒に指定する場合は、次のように WITH キーワードを使用して指定する必要があります。When the hint is specified with another option, the hint must be specified with the WITH keyword:

FROM t WITH (TABLOCK, INDEX(myindex))  

複数のテーブル ヒント間にはコンマを使用することをお勧めします。We recommend using commas between table hints.

重要

ヒントの分割にコンマの代わりにスペースを用いる方法は非推奨とされます。この機能は、Microsoft SQL Server の将来のバージョンで削除されます。This feature will be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションはできるだけ早く修正してください。Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible.Separating hints by spaces rather than commas is a deprecated feature: この機能は、Microsoft SQL Server の将来のバージョンで削除されます。This feature will be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションはできるだけ早く修正してください。Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible.

NOEXPANDNOEXPAND
クエリ オプティマイザーがクエリを処理する場合に、インデックス付きビューが展開されず、基になるテーブルがアクセスされないことを指定します。Specifies that any indexed views are not expanded to access underlying tables when the query optimizer processes the query. クエリ オプティマイザーは、ビューをクラスター化インデックスを持つテーブルのように取り扱います。The query optimizer treats the view like a table with clustered index. NOEXPAND はインデックス付きビューにのみ適用できます。NOEXPAND applies only to indexed views. 詳細については、「NOEXPAND の使用」を参照してください。For more information, see Using NOEXPAND.

INDEX (index_value [,... n ] ) | INDEX = ( index_value)INDEX (index_value [,... n ] ) | INDEX = ( index_value)
INDEX() 構文では、ステートメントを処理するときにクエリ オプティマイザーが使用する 1 つ以上のインデックスの名前または ID を指定します。The INDEX() syntax specifies the names or IDs of one or more indexes to be used by the query optimizer when it processes the statement. 一方、INDEX = 構文では、単一のインデックス値を指定します。The alternative INDEX = syntax specifies a single index value. 各テーブルに対して指定できるのは 1 つのインデックス ヒントだけです。Only one index hint per table can be specified.

クラスター化インデックスがある場合、INDEX(0) はクラスター化インデックスのスキャンを実行し、INDEX(1) はクラスター化インデックスのスキャンまたはシークを実行します。If a clustered index exists, INDEX(0) forces a clustered index scan and INDEX(1) forces a clustered index scan or seek. クラスター化インデックスがない場合、INDEX(0) はテーブル スキャンを実行し、INDEX(1) はエラーと見なされます。If no clustered index exists, INDEX(0) forces a table scan and INDEX(1) is interpreted as an error.

1 つのヒント リストの中で複数のインデックスが使用されている場合、重複するものは無視され、リスト内の残りのインデックスを使用してテーブルの行が取得されます。If multiple indexes are used in a single hint list, the duplicates are ignored and the rest of the listed indexes are used to retrieve the rows of the table. インデックス ヒント内のインデックスの順番は重要です。The order of the indexes in the index hint is significant. 複数のインデックス ヒントはインデックスの AND 処理も設定し、クエリ オプティマイザーはアクセスされる各インデックスに可能な限り多くの条件を適用します。A multiple index hint also enforces index ANDing, and the query optimizer applies as many conditions as possible on each index accessed. ヒント インデックスの集合に、クエリで参照される列のすべてが含まれているわけではない場合、SQL Server データベース エンジンSQL Server Database Engineがすべてのインデックス列を取得した後で、残りの列を取得するフェッチが実行されます。If the collection of hinted indexes do not include all columns referenced by the query, a fetch is performed to retrieve the remaining columns after the SQL Server データベース エンジンSQL Server Database Engine retrieves all the indexed columns.

注意

複数のインデックスを参照するインデックス ヒントが、スター結合のファクト テーブルで使用されている場合、オプティマイザーはそのインデックス ヒントを無視し、警告メッセージを返します。When an index hint referring to multiple indexes is used on the fact table in a star join, the optimizer ignores the index hint and returns a warning message. また、インデックス論理和は、インデックス ヒントが指定されたテーブルでは許可されません。Also, index ORing is not allowed for a table with an index hint specified.

テーブル ヒント内のインデックスの最大個数は、非クラスター化インデックスが 250 個です。The maximum number of indexes in the table hint is 250 nonclustered indexes.

KEEPIDENTITYKEEPIDENTITY
INSERT ステートメントで、BULK オプションが OPENROWSET と一緒に使用されているときにのみ適用できます。Is applicable only in an INSERT statement when the BULK option is used with OPENROWSET.

インポートしたデータ ファイルの ID 値 (複数可) を ID 列に使用することを指定します。Specifies that identity value or values in the imported data file are to be used for the identity column. KEEPIDENTITY を指定しない場合、この列の ID 値は確認されるのみでインポートされません。クエリ オプティマイザーは、テーブルの作成時に指定された seed および increment の値を基に一意な値を自動的に割り当てます。If KEEPIDENTITY is not specified, the identity values for this column are verified but not imported and the query optimizer automatically assigns unique values based on the seed and increment values specified during table creation.

重要

テーブルやビューの ID 列の値がデータ ファイルに含まれておらず、ID 列がテーブルの最終列でもない場合は、その ID 列をスキップする必要があります。If the data file does not contain values for the identity column in the table or view, and the identity column is not the last column in the table, you must skip the identity column. 詳細については、「フォーマット ファイルを使用したデータ フィールドのスキップ (SQL Server)」を参照してください。For more information, see Use a Format File to Skip a Data Field (SQL Server). ID 列のスキップに成功すると、クエリ オプティマイザーは、その ID 列の一意な値を、インポートされたテーブル行に自動的に割り当てます。If an identity column is skipped successfully, the query optimizer automatically assigns unique values for the identity column into the imported table rows.

このヒントを INSERT ... SELECT * FROM OPENROWSET(BULK...) ステートメントに使用する例については、「データの一括インポート時の ID 値の保持 (SQL Server)」を参照してください。For an example that uses this hint in an INSERT ... SELECT * FROM OPENROWSET(BULK...) statement, see Keep Identity Values When Bulk Importing Data (SQL Server).

テーブルの ID 値の確認については、「DBCC CHECKIDENT (Transact-SQL)」を参照してください。For information about checking the identity value for a table, see DBCC CHECKIDENT (Transact-SQL).

KEEPDEFAULTSKEEPDEFAULTS
INSERT ステートメントで、BULK オプションが OPENROWSET と一緒に使用されているときにのみ適用できます。Is applicable only in an INSERT statement when the BULK option is used with OPENROWSET.

データ レコードにテーブルの列値が含まれていない場合に、NULL の代わりにテーブル列の既定値を挿入することを指定します。Specifies insertion of a table column's default value, if any, instead of NULL when the data record lacks a value for the column.

このヒントを INSERT ...SELECT * FROM OPENROWSET(BULK...) ステートメントに使用する例については、「一括インポート中の NULL の保持または既定値の使用 (SQL Server)」を参照してください。For an example that uses this hint in an INSERT ... SELECT * FROM OPENROWSET(BULK...) statement, see Keep Nulls or Use Default Values During Bulk Import (SQL Server).

FORCESEEK [ (index_value(index_column_name [ ,... n ] )) ]FORCESEEK [ (index_value(index_column_name [ ,... n ] )) ]
クエリ オプティマイザーに対し、テーブルやビューのデータへのアクセス パスとしてインデックスのシーク操作のみを使用することを指定します。Specifies that the query optimizer use only an index seek operation as the access path to the data in the table or view.

注意

SQL Server 2008 R2SQL Server 2008 R2 SP1 以降では、インデックス パラメーターも指定できます。Starting with SQL Server 2008 R2SQL Server 2008 R2 SP1, index parameters can also be specified. その場合、一度でも指定されたインデックス列が使用されると、クエリ オプティマイザーでは指定されたインデックスを介したインデックスのシーク操作のみが検討されます。In that case, the query optimizer considers only index seek operations through the specified index using at least the specified index columns.

index_valueindex_value
インデックスの名前またはインデックスの ID 値です。Is the index name or index ID value. インデックス ID 0 (ヒープ) は指定できません。The index ID 0 (heap) cannot be specified. インデックスの名前または ID を返すには、sys.indexes カタログ ビューにクエリを実行します。To return the index name or ID, query the sys.indexes catalog view.

index_column_nameindex_column_name
シーク操作に含めるインデックス列の名前です。Is the name of the index column to include in the seek operation. インデックス パラメーターを使用して FORCESEEK を指定することは、INDEX ヒントを使用して FORCESEEK を使用することと同じです。Specifying FORCESEEK with index parameters is similar to using FORCESEEK with an INDEX hint. ただし、シーク対象のインデックスとシーク操作で考慮するインデックス列の両方を指定することで、クエリ オプティマイザーで使用されるアクセス パスをより詳細に制御できるようになります。However, you can achieve greater control over the access path used by the query optimizer by specifying both the index to seek on and the index columns to consider in the seek operation. オプティマイザーでは、必要に応じて、追加の列が検討される場合もあります。The optimizer may consider additional columns if needed. たとえば、非クラスター化インデックスが指定されている場合、オプティマイザーでは、指定された列に加え、クラスター化インデックスのキー列を使用することもできます。For example, if a nonclustered index is specified, the optimizer may choose to use clustered index key columns in addition to the specified columns.

FORCESEEK ヒントは以下の方法で指定できます。The FORCESEEK hint can be specified in the following ways.

構文Syntax Example [説明]Description
インデックスまたは INDEX ヒントを使用しない場合Without an index or INDEX hint FROM dbo.MyTable WITH (FORCESEEK) クエリ オプティマイザーでは、関連するインデックスを介してテーブルやビューにアクセスするためのインデックスのシーク操作のみが検討されます。The query optimizer considers only index seek operations to access the table or view through any relevant index.
INDEX ヒントと組み合わせた場合Combined with an INDEX hint FROM dbo.MyTable WITH (FORCESEEK, INDEX (MyIndex)) クエリ オプティマイザーでは、指定されたインデックスを介してテーブルやビューにアクセスするためのインデックスのシーク操作のみが検討されます。The query optimizer considers only index seek operations to access the table or view through the specified index.
インデックスとインデックス列を指定してパラメーター化する場合Parameterized by specifying an index and index columns FROM dbo.MyTable WITH (FORCESEEK (MyIndex (col1, col2, col3))) 少なくとも指定されたインデックス列を使用した場合、クエリ オプティマイザーでは、指定されたインデックスを介してテーブルやビューにアクセスするためのインデックスのシーク操作のみが検討されます。The query optimizer considers only index seek operations to access the table or view through the specified index using at least the specified index columns.

(インデックス パラメーターを使用するかどうかにかかわらず) FORCESEEK ヒントを使用する際は、次のガイドラインを考慮してください。When using the FORCESEEK hint (with or without index parameters), consider the following guidelines:

  • ヒントは、テーブル ヒントまたはクエリ ヒントとして指定できます。The hint can be specified as a table hint or as a query hint. クエリ ヒントの詳細については、「クエリ ヒント (Transact-SQL)」を参照してください。For more information about query hints, see Query Hints (Transact-SQL).
  • インデックス付きビューに FORCESEEK を適用するには、NOEXPAND ヒントも指定する必要があります。To apply FORCESEEK to an indexed view, the NOEXPAND hint must also be specified.
  • ヒントは、テーブルまたはビューごとに 1 回だけ適用できます。The hint can be applied at most once per table or view.
  • ヒントは、リモート データ ソースに指定できません。The hint cannot be specified for a remote data source. インデックス ヒントを使用して FORCESEEK を指定すると、エラー 7377 が返されます。また、インデックス ヒントなしで FORCESEEK を使用すると、エラー 8180 が返されます。Error 7377 is returned when FORCESEEK is specified with an index hint and error 8180 is returned when FORCESEEK is used without an index hint.
  • FORCESEEK が原因でプランが見つからない場合、エラー 8622 が返されます。If FORCESEEK causes no plan to be found, error 8622 is returned.

インデックス パラメーターを使用して FORCESEEK を指定する際は、次のガイドラインと制限が適用されます。When FORCESEEK is specified with index parameters, the following guidelines and restrictions apply:

  • ヒントは、INSERT、UPDATE、または DELETE ステートメントの対象であるテーブルには指定できません。The hint cannot be specified for a table that is the target of an INSERT, UPDATE, or DELETE statement.
  • ヒントは、INDEX ヒントまたは別の FORCESEEK ヒントと組み合わせて指定することができません。The hint cannot be specified in combination with either an INDEX hint or another FORCESEEK hint.
  • 少なくとも 1 列を指定する必要があり、先頭のキー列にする必要があります。At least one column must be specified and it must be the leading key column.
  • 追加のインデックス列を指定できますが、キー列は省略できません。Additional index columns can be specified, however, key columns cannot be skipped. たとえば、指定されたインデックスに ab、および c というキー列が含まれている場合、有効な構文には FORCESEEK (MyIndex (a)) および FORCESEEK (MyIndex (a, b) が含まれます。For example, if the specified index contains the key columns a, b, and c, valid syntax would include FORCESEEK (MyIndex (a)) and FORCESEEK (MyIndex (a, b). 無効な構文には、FORCESEEK (MyIndex (c))FORCESEEK (MyIndex (a, c) が含まれます。Invalid syntax would include FORCESEEK (MyIndex (c)) and FORCESEEK (MyIndex (a, c).
  • ヒントで指定された列名の順序は、参照先のインデックスでの列の順序と一致させる必要があります。The order of column names specified in the hint must match the order of the columns in the referenced index.
  • インデックス キーの定義にない列は、指定できません。Columns that are not in the index key definition cannot be specified. たとえば、非クラスター化インデックスでは、定義されたインデックス キー列のみを指定できます。For example, in a nonclustered index, only the defined index key columns can be specified. 自動的にインデックスに含まれるクラスター化キー列は指定できませんが、オプティマイザーでは使用できます。Clustered key columns that are automatically included in the index cannot be specified, but may be used by the optimizer.
  • xVelocity メモリ最適化列ストア インデックスは、インデックス パラメーターとして指定できません。An xVelocity memory optimized columnstore index cannot be specified as an index parameter. エラー 366 が返されます。Error 366 is returned.
  • インデックス定義を変更すると (列の追加や削除など)、そのインデックスを参照するクエリに対する変更も必要になる場合があります。Modifying the index definition (for example, by adding or removing columns) may require modifications to the queries that reference that index.
  • ヒントを使用すると、オプティマイザーでは、テーブル上の空間インデックスまたは XML インデックスが検討されなくなります。The hint prevents the optimizer from considering any spatial or XML indexes on the table.
  • ヒントは、FORCESCAN ヒントと組み合わせて指定することはできません。The hint cannot be specified in combination with the FORCESCAN hint.
  • パーティション インデックスでは、SQL ServerSQL Server によって暗黙的に追加されたパーティション分割列を FORCESEEK ヒントで指定できません。For partitioned indexes, the partitioning column implicitly added by SQL ServerSQL Server cannot be specified in the FORCESEEK hint.

注意事項

パラメーターを使用して FORCESEEK を指定すると、オプティマイザーで考慮できるプラン数の制限は、パラメーターなしで FORCESEEK を指定した場合よりも多くなります。Specifying FORCESEEK with parameters limits the number of plans that can be considered by the optimizer more than when specifying FORCESEEK without parameters. これにより、Plan cannot be generated というエラーが生じる回数が増加する可能性があります。This may cause a Plan cannot be generated error to occur in more cases. 将来のリリースでは、クエリ オプティマイザーに対して内部変更を行うため、より多くのプランを考慮できるようになります。In a future release, internal modifications to the query optimizer may allow more plans to be considered.

FORCESCAN 適用対象:SQL Server 2008 R2SQL Server 2008 R2 SP1 から SQL Server 2017SQL Server 2017FORCESCAN Applies to: SQL Server 2008 R2SQL Server 2008 R2 SP1 through SQL Server 2017SQL Server 2017. クエリ オプティマイザーに対し、参照されているテーブルやビューへのアクセス パスとして、インデックスのスキャン操作のみを使うことを指定します。Specifies that the query optimizer use only an index scan operation as the access path to the referenced table or view. FORCESCAN ヒントは、オプティマイザーが影響を受ける行数を過小評価し、スキャン操作ではなくシーク操作を選択するクエリに役立つ場合があります。The FORCESCAN hint can be useful for queries in which the optimizer underestimates the number of affected rows and chooses a seek operation rather than a scan operation. この場合、操作に許可されるメモリの量は少なすぎて、クエリのパフォーマンスに影響します。When this occurs, the amount of memory granted for the operation is too small and query performance is impacted.

FORCESCAN を指定する際には、INDEX ヒントを使用してもしなくてもかまいません。FORCESCAN can be specified with or without an INDEX hint. インデックス ヒントと組み合わせると (INDEX = index_name, FORCESCAN)、クエリ オプティマイザーでは、参照されるテーブルにアクセスする際に、指定されたインデックスを介したアクセス パスのみが検討されます。When combined with an index hint, (INDEX = index_name, FORCESCAN), the query optimizer considers only scan access paths through the specified index when accessing the referenced table. インデックス ヒント INDEX(0) ベース テーブルのテーブル スキャン操作を強制するには、FORCESCAN を指定できます。FORCESCAN can be specified with the index hint INDEX(0) to force a table scan operation on the base table.

パーティション テーブルやパーティション インデックスの場合、FORCESCAN が適用されるのは、クエリの述語評価によってパーティションが削除された後です。For partitioned tables and indexes, FORCESCAN is applied after partitions have been eliminated through query predicate evaluation. つまり、スキャンは、テーブル全体ではなく、残りのパーティションのみに適用されます。This means that the scan is applied only to the remaining partitions and not to the entire table.

FORCESCAN ヒントには次の制限があります。The FORCESCAN hint has the following restrictions:

  • ヒントは、INSERT、UPDATE、または DELETE ステートメントの対象であるテーブルには指定できません。The hint cannot be specified for a table that is the target of an INSERT, UPDATE, or DELETE statement.
  • ヒントは、複数のインデックス ヒントと併用できません。The hint cannot be used with more than one index hint.
  • ヒントを使用すると、オプティマイザーでは、テーブル上の空間インデックスまたは XML インデックスが検討されなくなります。The hint prevents the optimizer from considering any spatial or XML indexes on the table.
  • ヒントは、リモート データ ソースに指定できません。The hint cannot be specified for a remote data source.
  • ヒントは、FORCESEEK ヒントと組み合わせて指定することはできません。The hint cannot be specified in combination with the FORCESEEK hint.

HOLDLOCKHOLDLOCK
SERIALIZABLE に相当します。Is equivalent to SERIALIZABLE. 詳細については、後の「SERIALIZABLE」を参照してください。For more information, see SERIALIZABLE later in this topic. HOLDLOCK は、指定されたテーブルやビューに対してのみ、また、使用されているステートメントによって定義されたトランザクションの間のみ適用されます。HOLDLOCK applies only to the table or view for which it is specified and only for the duration of the transaction defined by the statement that it is used in. HOLDLOCK は、FOR BROWSE オプションを含む SELECT ステートメントでは使用できません。HOLDLOCK cannot be used in a SELECT statement that includes the FOR BROWSE option.

IGNORE_CONSTRAINTSIGNORE_CONSTRAINTS
INSERT ステートメントで、BULK オプションが OPENROWSET と一緒に使用されているときにのみ適用できます。Is applicable only in an INSERT statement when the BULK option is used with OPENROWSET.

テーブルに対する制約を一括インポート操作時に無視することを指定します。Specifies that any constraints on the table are ignored by the bulk-import operation. 既定では、INSERT は Unique 制約と CHECK 制約および主キー制約と外部キー制約をチェックします。By default, INSERT checks Unique Constraints and Check Constraints and Primary and Foreign Key Constraints. 一括インポート操作の際に IGNORE_CONSTRAINTS を指定している場合、インポート対象のテーブルに対する制約が無視されます。When IGNORE_CONSTRAINTS is specified for a bulk-import operation, INSERT must ignore these constraints on a target table. UNIQUE、PRIMARY KEY、または NOT NULL の各制約を無効にすることはできません。Note that you cannot disable UNIQUE, PRIMARY KEY, or NOT NULL constraints.

制約に違反する行が入力データに含まれている場合に、CHECK 制約および FOREIGN KEY 制約を無効化することができます。You might want to disable CHECK and FOREIGN KEY constraints if the input data contains rows that violate constraints. CHECK 制約および FOREIGN KEY 制約を無効化することによって、データをインポートしてから、Transact-SQLTransact-SQL ステートメントを使用してデータをクリーンアップできます。By disabling the CHECK and FOREIGN KEY constraints, you can import the data and then use Transact-SQLTransact-SQL statements to clean up the data.

ただし、CHECK 制約および FOREIGN KEY 制約を無視すると、操作の後、テーブルに設定されている制約のうち、無視された制約は sys.check_constraints カタログ ビューまたは sys.foreign_keys カタログ ビューで is_not_trusted とマークされます。However, when CHECK and FOREIGN KEY constraints are ignored, each ignored constraint on the table is marked as is_not_trusted in the sys.check_constraints or sys.foreign_keys catalog view after the operation. テーブル全体の制約は、任意の時点で必ず検証してください。At some point, you should check the constraints on the whole table. 一括インポート操作の前にテーブルが空白になっていない場合、制約の再検証にかかるコストは、CHECK 制約および FOREIGN KEY 制約を増分データに適用することによるコストを上回る可能性があります。If the table was not empty before the bulk import operation, the cost of revalidating the constraint may exceed the cost of applying CHECK and FOREIGN KEY constraints to the incremental data.

IGNORE_TRIGGERSIGNORE_TRIGGERS
INSERT ステートメントで、BULK オプションが OPENROWSET と一緒に使用されているときにのみ適用できます。Is applicable only in an INSERT statement when the BULK option is used with OPENROWSET.

テーブルに対して定義されたトリガーを、一括インポート操作時に無視することを指定します。Specifies that any triggers defined on the table are ignored by the bulk-import operation. 既定では、INSERT はトリガーを適用します。By default, INSERT applies triggers.

アプリケーションがいずれのトリガーにも依存しておらず、パフォーマンスの最大化が重要な場合にのみ、IGNORE_TRIGGERS を使用してください。Use IGNORE_TRIGGERS only if your application does not depend on any triggers and maximizing performance is important.

NOLOCKNOLOCK
READUNCOMMITTED に相当します。Is equivalent to READUNCOMMITTED. 詳細については、後の「READUNCOMMITTED」を参照してください。For more information, see READUNCOMMITTED later in this topic.

注意

UPDATE ステートメントまたは DELETE ステートメントの場合: この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature.For UPDATE or DELETE statements: この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

NOWAITNOWAIT
テーブルでロックがかかったらすぐにメッセージを返すようにデータベース エンジンDatabase Engineを設定します。Instructs the データベース エンジンDatabase Engine to return a message as soon as a lock is encountered on the table. NOWAIT は、特定のテーブルに SET LOCK_TIMEOUT 0 を指定することに相当します。NOWAIT is equivalent to specifying SET LOCK_TIMEOUT 0 for a specific table. NOWAIT ヒントは、TABLOCK ヒントも指定されている場合は機能しません。The NOWAIT hint does not work when the TABLOCK hint is also included. TABLOCK ヒントを使用している場合に待機しないでクエリを終了するには、代わりにクエリの前に SETLOCK_TIMEOUT 0; を指定します。To terminate a query without waiting when using the TABLOCK hint, preface the query with SETLOCK_TIMEOUT 0; instead.

PAGLOCKPAGLOCK
通常使用される行やキーに対する個々のロックまたは単一のテーブル ロックの代わりに、ページ ロックを使用します。Takes page locks either where individual locks are ordinarily taken on rows or keys, or where a single table lock is ordinarily taken. 既定では、操作に適したロック モードを使用します。By default, uses the lock mode appropriate for the operation. SNAPSHOT 分離レベルで実行中のトランザクションにおいてこのオプションを指定しても、UPDLOCK や HOLDLOCK など、ロックが必要な他のテーブル ヒントと組み合わせて指定しない限り、ページ ロックは取得されません。When specified in transactions operating at the SNAPSHOT isolation level, page locks are not taken unless PAGLOCK is combined with other table hints that require locks, such as UPDLOCK and HOLDLOCK.

READCOMMITTEDREADCOMMITTED
読み取り操作が、ロックまたは行のバージョン管理を使用して、READ COMMITTED 分離レベルのルールに従うことを指定します。Specifies that read operations comply with the rules for the READ COMMITTED isolation level by using either locking or row versioning. データベース オプション READ_COMMITTED_SNAPSHOT が OFF の場合、データベース エンジンDatabase Engineはデータの読み取り時に共有ロックを取得し、読み取り操作が完了するとロックを解除します。If the database option READ_COMMITTED_SNAPSHOT is OFF, the データベース エンジンDatabase Engine acquires shared locks as data is read and releases those locks when the read operation is completed. データベース オプション READ_COMMITTED_SNAPSHOT が ON の場合、データベース エンジンDatabase Engineはロックを取得せずに行のバージョン管理を使用します。If the database option READ_COMMITTED_SNAPSHOT is ON, the データベース エンジンDatabase Engine does not acquire locks and uses row versioning. 分離レベルについての詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。For more information about isolation levels, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

注意

UPDATE ステートメントまたは DELETE ステートメントの場合: この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature.For UPDATE or DELETE statements: この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

READCOMMITTEDLOCKREADCOMMITTEDLOCK
読み取り操作が、ロックを使用して、READ COMMITTED 分離レベルのルールに従うことを指定します。Specifies that read operations comply with the rules for the READ COMMITTED isolation level by using locking. READ_COMMITTED_SNAPSHOT データベース オプションの設定にかかわらず、データベース エンジンDatabase Engine はデータの読み取り時に共有ロックを取得し、読み取り操作が完了するとロックを解除します。The データベース エンジンDatabase Engine acquires shared locks as data is read and releases those locks when the read operation is completed, regardless of the setting of the READ_COMMITTED_SNAPSHOT database option. 分離レベルについての詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。For more information about isolation levels, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL). このヒントは、INSERT ステートメントの対象のテーブルには指定できません。指定すると、エラー 4140 が返されます。This hint cannot be specified on the target table of an INSERT statement; error 4140 is returned.

READPASTREADPAST
他のトランザクションによってロックされている行を、データベース エンジンDatabase Engine が読み取らないことを指定します。Specifies that the データベース エンジンDatabase Engine not read rows that are locked by other transactions. READPAST を指定すると、行レベルのロックはスキップされますが、ページレベルのロックはスキップされません。When READPAST is specified, row-level locks are skipped but page-level locks are not skipped. つまり、データベース エンジンDatabase Engineは、ロックが解除されるまで現在のトランザクションをブロックする代わりに、行をスキップします。That is, the データベース エンジンDatabase Engine skips past the rows instead of blocking the current transaction until the locks are released. たとえば、テーブル T1 に整数型の列が 1 つあり、値 1、2、3、4、5 が格納されているとします。For example, assume table T1 contains a single integer column with the values of 1, 2, 3, 4, 5. このテーブルに対してトランザクション A で値 3 を 8 に変更し、この変更をまだコミットしていない間に SELECT * FROM T1 (READPAST) を実行すると、取得される値は 1、2、4、5 となります。If transaction A changes the value of 3 to 8 but has not yet committed, a SELECT * FROM T1 (READPAST) yields values 1, 2, 4, 5. READPAST は主に、SQL ServerSQL Server テーブルを使用する作業キューの実装時に、ロックの競合を減らすために使用します。READPAST is primarily used to reduce locking contention when implementing a work queue that uses a SQL ServerSQL Server table. READPAST を使用するキュー リーダーは、他のトランザクションによってロックされたキュー エントリを、ロックが解除されるまで待たずにスキップして、次に使用可能なキュー エントリへ進みます。A queue reader that uses READPAST skips past queue entries locked by other transactions to the next available queue entry, without having to wait until the other transactions release their locks.

READPAST は、UPDATE ステートメントまたは DELETE ステートメントで参照されるテーブル、および FROM 句で参照されるテーブルで指定できます。READPAST can be specified for any table referenced in an UPDATE or DELETE statement, and any table referenced in a FROM clause. UPDATE ステートメントで READPAST を指定した場合、ステートメント内での指定場所にかかわらず、更新対象レコード特定のためのデータ読み取り時にだけ適用されます。When specified in an UPDATE statement, READPAST is applied only when reading data to identify which records to update, regardless of where in the statement it is specified. INSERT ステートメントの INTO 句では、テーブルに READPAST を指定することができません。READPAST cannot be specified for tables in the INTO clause of an INSERT statement. READPAST を使用する更新操作や削除操作は、外部キーやインデックス付きビューの読み取り時、またはセカンダリ インデックスの変更時にブロックを行う場合があります。Update or delete operations that use READPAST may block when reading foreign keys or indexed views, or when modifying secondary indexes.

READPAST は、READ COMMITTED 分離レベルまたは REPEATABLE READ 分離レベルで実行中のトランザクションでのみ指定できます。READPAST can only be specified in transactions operating at the READ COMMITTED or REPEATABLE READ isolation levels. SNAPSHOT 分離レベルで実行中のトランザクションにおいてこのオプションを指定する場合、UPDLOCK や HOLDLOCK など、ロックが必要な他のテーブル ヒントと組み合わせて指定する必要があります。When specified in transactions operating at the SNAPSHOT isolation level, READPAST must be combined with other table hints that require locks, such as UPDLOCK and HOLDLOCK.

READ_COMMITTED_SNAPSHOT データベース オプションが ON に設定され、次のいずれかの条件に該当する場合、READPAST テーブル ヒントは指定できません。The READPAST table hint cannot be specified when the READ_COMMITTED_SNAPSHOT database option is set to ON and either of the following conditions is true:

  • セッションのトランザクション分離レベルが READ COMMITTED の場合The transaction isolation level of the session is READ COMMITTED.
  • READCOMMITTED テーブル ヒントもクエリで指定されている場合The READCOMMITTED table hint is also specified in the query.

このような場合に READPAST ヒントを指定するには、READCOMMITTED テーブル ヒントがある場合は削除し、クエリに READCOMMITTEDLOCK テーブル ヒントを含めます。To specify the READPAST hint in these cases, remove the READCOMMITTED table hint if present, and include the READCOMMITTEDLOCK table hint in the query.

READUNCOMMITTEDREADUNCOMMITTED
ダーティ リードを許可することを指定します。Specifies that dirty reads are allowed. 現在のトランザクションによるデータ読み取りが他のトランザクションによって変更されないようにするため共有ロックを実行しません。また、他のトランザクションによって排他ロックが設定されていても、ロックされたデータの現在のトランザクションによる読み取りはブロックされません。No shared locks are issued to prevent other transactions from modifying data read by the current transaction, and exclusive locks set by other transactions do not block the current transaction from reading the locked data. ダーティ リードを許可するとコンカレンシーが高まりますが、他のトランザクションによってロールバックされているデータ変更を読み取る可能性があります。Allowing dirty reads can cause higher concurrency, but at the cost of reading data modifications that then are rolled back by other transactions. この結果、トランザクションでエラーが発生したり、コミットされていないデータがユーザーに提示されたり、レコードが重複表示されたりまったく表示されなかったりする場合があります。This may generate errors for your transaction, present users with data that was never committed, or cause users to see records twice (or not at all).

READUNCOMMITTED ヒントと NOLOCK ヒントはデータのロックにのみ適用されます。READUNCOMMITTED and NOLOCK hints apply only to data locks. READUNCOMMITTED ヒントおよび NOLOCK ヒントを含むクエリを含め、すべてのクエリは、コンパイル中と実行中にスキーマ安定度 (Sch-S) ロックを取得します。All queries, including those with READUNCOMMITTED and NOLOCK hints, acquire Sch-S (schema stability) locks during compilation and execution. このため、同時実行トランザクションがテーブルの Sch-M (スキーマ修正) ロックを保持している場合、クエリはブロックされます。Because of this, queries are blocked when a concurrent transaction holds a Sch-M (schema modification) lock on the table. たとえば、データ定義言語 (DDL) 操作では、テーブルのスキーマ情報を変更する前にスキーマ修正 (Sch-M) ロックを取得します。For example, a data definition language (DDL) operation acquires a Sch-M lock before it modifies the schema information of the table. READUNCOMMITTED ヒントまたは NOLOCK ヒントを指定して実行しているクエリを含め、すべての同時実行クエリは、スキーマ安定度 (Sch-S) ロックを取得しようとするとブロックされます。Any concurrent queries, including those running with READUNCOMMITTED or NOLOCK hints, are blocked when attempting to acquire a Sch-S lock. 一方、スキーマ安定度 (Sch-S) ロックを保持するクエリによって、スキーマ修正 (Sch-M) ロックを取得しようとする同時実行トランザクションはブロックされます。Conversely, a query holding a Sch-S lock blocks a concurrent transaction that attempts to acquire a Sch-M lock.

READUNCOMMITTED および NOLOCK は、挿入、更新、削除の各操作によって変更されるテーブルに対しては指定できません。READUNCOMMITTED and NOLOCK cannot be specified for tables modified by insert, update, or delete operations. SQL ServerSQL Server クエリ オプティマイザーは、UPDATE ステートメントまたは DELETE ステートメントの対象テーブルに適用する FROM 句内の READUNCOMMITTED ヒントおよび NOLOCK ヒントを無視します。The SQL ServerSQL Server query optimizer ignores the READUNCOMMITTED and NOLOCK hints in the FROM clause that apply to the target table of an UPDATE or DELETE statement.

注意

FROM 句を UPDATE または DELETE ステートメントの対象テーブルに適用する場合、この句での READUNCOMMITTED ヒントと NOLOCK ヒントの使用は、将来のバージョンの SQL ServerSQL Server でサポートされなくなる予定です。Support for use of the READUNCOMMITTED and NOLOCK hints in the FROM clause that apply to the target table of an UPDATE or DELETE statement will be removed in a future version of SQL ServerSQL Server. 新しい開発作業ではこのコンテキストでのヒントの使用を避け、現在このヒントを使用しているアプリケーションは変更を検討してください。Avoid using these hints in this context in new development work, and plan to modify applications that currently use them.

次のいずれかを使用することによって、ロックの競合を最小限に抑えながら、コミットされていないデータ変更のダーティ リードからトランザクションを保護することができます。You can minimize locking contention while protecting transactions from dirty reads of uncommitted data modifications by using either of the following:

  • READ COMMITTED 分離レベル。READ_COMMITTED_SNAPSHOT データベース オプションを ON に設定します。The READ COMMITTED isolation level with the READ_COMMITTED_SNAPSHOT database option set ON.
  • SNAPSHOT 分離レベル。The SNAPSHOT isolation level.

分離レベルについての詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。For more information about isolation levels, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

注意

READUNCOMMITTED が指定されているときにエラー メッセージ 601 が表示された場合は、デッドロック エラー (1205) を解決するときと同じように解決し、ステートメントを再実行してください。If you receive the error message 601 when READUNCOMMITTED is specified, resolve it as you would a deadlock error (1205), and retry your statement.

REPEATABLEREADREPEATABLEREAD
REPEATABLE READ 分離レベルで実行しているトランザクションと同じロック セマンティクスでスキャンを実行することを指定します。Specifies that a scan is performed with the same locking semantics as a transaction running at REPEATABLE READ isolation level. 分離レベルについての詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。For more information about isolation levels, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

ROWLOCKROWLOCK
通常取得されるページ ロックまたはテーブル ロックの代わりに、行ロックを取得することを指定します。Specifies that row locks are taken when page or table locks are ordinarily taken. SNAPSHOT 分離レベルで実行中のトランザクションにおいてこのオプションを指定しても、UPDLOCK や HOLDLOCK など、ロックが必要な他のテーブル ヒントと組み合わせて指定しない限り、行ロックは取得されません。When specified in transactions operating at the SNAPSHOT isolation level, row locks are not taken unless ROWLOCK is combined with other table hints that require locks, such as UPDLOCK and HOLDLOCK.

SERIALIZABLESERIALIZABLE
HOLDLOCK に相当します。Is equivalent to HOLDLOCK. 共有ロックがより制限的になります。テーブルまたはデータ ページが不要になったときに、トランザクションが完了しているかどうかにかかわらず共有ロックが解除されるのではなく、共有ロックはトランザクションが完了するまで保持されます。Makes shared locks more restrictive by holding them until a transaction is completed, instead of releasing the shared lock as soon as the required table or data page is no longer needed, whether the transaction has been completed or not. SERIALIZABLE 分離レベルで実行しているトランザクションと同じセマンティクスで、スキャンが実行されます。The scan is performed with the same semantics as a transaction running at the SERIALIZABLE isolation level. 分離レベルについての詳細については、「SET TRANSACTION ISOLATION LEVEL (Transact-SQL)」を参照してください。For more information about isolation levels, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

SNAPSHOTSNAPSHOT
適用対象: SQL Server 2014 (12.x)SQL Server 2014 (12.x) から SQL Server 2017SQL Server 2017Applies to: SQL Server 2014 (12.x)SQL Server 2014 (12.x) through SQL Server 2017SQL Server 2017.

メモリ最適化されたテーブルは、SNAPSHOT 分離でアクセスされます。The memory-optimized table is accessed under SNAPSHOT isolation. SNAPSHOT は、メモリ最適化されたテーブルだけで使用できまます (ディスク ベースのテーブルでは使用できません)。SNAPSHOT can only be used with memory-optimized tables (not with disk-based tables). 詳細については、「メモリ最適化テーブルの概要」を参照してください。For more information, see Introduction to Memory-Optimized Tables.

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 = integerSPATIAL_WINDOW_MAX_CELLS = integer
適用対象: SQL Server 2012 (11.x)SQL Server 2012 (11.x) から SQL Server 2017SQL Server 2017Applies to: SQL Server 2012 (11.x)SQL Server 2012 (11.x) through SQL Server 2017SQL Server 2017.
geometry オブジェクトや geography オブジェクトのテセレーションに使用するセルの最大数を指定します。Specifies the maximum number of cells to use for tessellating a geometry or geography object. は、1 から 8192 の範囲の値です。number is a value between 1 and 8192.

このオプションを使用すると、プライマリとセカンダリのフィルターの実行時間の間のトレードオフを調整することによって、クエリの実行時間を微調整できます。This option allows for fine-tuning of query execution time by adjusting the tradeoff between primary and secondary filter execution time. 値を大きくすると、セカンダリ フィルターの実行時間が短縮されますが、プライマリ フィルターの実行時間が増加します。値を小さくすると、プライマリ フィルターの実行時間が短縮されますが、セカンダリ フィルターの実行時間が増加します。A larger number reduces secondary filter execution time, but increases primary execution filter time and a smaller number decreases primary filter execution time, but increase secondary filter execution. 密度の高い空間データの場合は、大きい値を指定して、プライマリ フィルターでより適切な近似値を提供し、セカンダリ フィルターの実行時間を減少させることで、実行時間を短縮させます。For denser spatial data, a higher number should produce a faster execution time by giving a better approximation with the primary filter and reducing secondary filter execution time. 密度の低いデータでは、小さい値を指定して、プライマリ フィルターの実行時間を短縮させます。For sparser data, a lower number will decrease the primary filter execution time.

このオプションは、手動と自動の両方のグリッド テセレーションに使用できます。This option works for both manual and automatic grid tessellations.

TABLOCKTABLOCK
取得したロックがテーブル レベルで適用されることを指定します。Specifies that the acquired lock is applied at the table level. 取得されるロックの種類は、実行されるステートメントによって異なります。The type of lock that is acquired depends on the statement being executed. たとえば、SELECT ステートメントを実行すると、共有ロックが取得されます。For example, a SELECT statement may acquire a shared lock. TABLOCK を指定することで、行レベルまたはページ レベルではなくテーブル全体に共有ロックが適用されます。By specifying TABLOCK, the shared lock is applied to the entire table instead of at the row or page level. HOLDLOCK も指定してある場合は、テーブル ロックがトランザクション終了まで保持されます。If HOLDLOCK is also specified, the table lock is held until the end of the transaction.

INSERT INTO <target_table> SELECT <columns> FROM <source_table> ステートメントを使用してデータをヒープにインポートするときに、対象テーブルに対して TABLOCK ヒントを指定すると、そのステートメントに対してログ記録とロックの最適化を有効にすることができます。When importing data into a heap by using the INSERT INTO <target_table> SELECT <columns> FROM <source_table> statement, you can enable optimized logging and locking for the statement by specifying the TABLOCK hint for the target table. データベース復旧モデルが単純復旧モデルまたは一括ログ復旧モデルに設定されている必要もあります。In addition, the recovery model of the database must be set to simple or bulk-logged. 詳細については、「INSERT (Transact-SQL)」を参照してください。For more information, see INSERT (Transact-SQL).

テーブルにデータをインポートするため、OPENROWSET 一括行セット プロバイダーで TABLOCK を使用すると、対象テーブルへのデータ読み込みを、ログ記録とロックを最適化して、複数のクライアントで同時に行うことができます。When used with the OPENROWSET bulk rowset provider to import data into a table, TABLOCK enables multiple clients to concurrently load data into the target table with optimized logging and locking. 詳細については、「一括インポートで最小ログ記録を行うための前提条件」次を参照してください。For more information, see Prerequisites for Minimal Logging in Bulk Import.

TABLOCKXTABLOCKX
テーブルに排他ロックを使用することを指定します。Specifies that an exclusive lock is taken on the table.

UPDLOCKUPDLOCK
更新ロックを使用することと、これをトランザクション終了まで保持することを指定します。Specifies that update locks are to be taken and held until the transaction completes. UPDLOCK を使用すると、行レベルまたはページ レベルの読み取り操作のみに更新ロックが適用されます。UPDLOCK takes update locks for read operations only at the row-level or page-level. UPDLOCK を TABLOCK と組み合わせたり、なんらかの理由でテーブル レベルのロックが使用されたりすると、代わりに排他 (X) ロックが取得されます。If UPDLOCK is combined with TABLOCK, or a table-level lock is taken for some other reason, an exclusive (X) lock will be taken instead.

UPDLOCK を指定すると、READCOMMITTED および READCOMMITTEDLOCK 分離レベル ヒントが無視されます。When UPDLOCK is specified, the READCOMMITTED and READCOMMITTEDLOCK isolation level hints are ignored. たとえば、セッションの分離レベルを SERIALIZABLE に設定し、クエリで (UPDLOCK, READCOMMITTED) を指定すると、READCOMMITTED ヒントは無視され、トランザクションは SERIALIZABLE 分離レベルを使用して実行されます。For example, if the isolation level of the session is set to SERIALIZABLE and a query specifies (UPDLOCK, READCOMMITTED), the READCOMMITTED hint is ignored and the transaction is run using the SERIALIZABLE isolation level.

XLOCKXLOCK
排他ロックを使用することと、これをトランザクション終了まで保持することを指定します。Specifies that exclusive locks are to be taken and held until the transaction completes. ROWLOCK、PAGLOCK、または TABLOCK と組み合わせて指定すると、排他ロックは適切な粒度レベルに適用されます。If specified with ROWLOCK, PAGLOCK, or TABLOCK, the exclusive locks apply to the appropriate level of granularity.

RemarksRemarks

テーブルがクエリ プランによってアクセスされているのではない場合、テーブル ヒントは無視されます。The table hints are ignored if the table is not accessed by the query plan. これは、オプティマイザーがテーブルにまったくアクセスしないことを選択した結果であるか、またはインデックス付きビューが代わりにアクセスされるためである可能性があります。This may be caused by the optimizer choosing not to access the table at all, or because an indexed view is accessed instead. 後者の場合、OPTION (EXPAND VIEWS) クエリ ヒントを使用することで、インデックス付きビューへのアクセスを防ぐことができます。In the latter case, accessing an indexed view can be prevented by using the OPTION (EXPAND VIEWS) query hint.

すべてのロック ヒントが、クエリ プランによってアクセスされているすべてのテーブルおよびビュー (ビューで参照されているテーブルおよびビューを含む) に反映されます。All lock hints are propagated to all the tables and views that are accessed by the query plan, including tables and views referenced in a view. また、SQL ServerSQL Server は、対応するロックの一貫性チェックを実行します。Also, SQL ServerSQL Server performs the corresponding lock consistency checks.

行レベルのロックを取得するロック ヒント ROWLOCK、UPDLOCK、および XLOCK では、実際のデータ行ではなくインデックス キーに対してロックが実行される場合があります。Lock hints ROWLOCK, UPDLOCK, AND XLOCK that acquire row-level locks may place locks on index keys rather than the actual data rows. たとえば、テーブルに非クラスター化インデックスがあり、ロック ヒントを使用する SELECT ステートメントがカバーするインデックスによって処理される場合、ベース テーブルのデータ行ではなく、カバーするインデックスのインデックス キーに対してロックが取得されます。For example, if a table has a nonclustered index, and a SELECT statement using a lock hint is handled by a covering index, a lock is acquired on the index key in the covering index rather than on the data row in the base table.

テーブルに計算列があり、その計算列が、別のテーブル内の列にアクセスする式や関数によって計算される場合、テーブル ヒントがそのテーブル上で使用されることや、反映されることはありません。If a table contains computed columns that are computed by expressions or functions accessing columns in other tables, the table hints are not used on those tables and are not propagated. たとえば、クエリ内のテーブルに NOLOCK テーブル ヒントが指定されているものとします。For example, a NOLOCK table hint is specified on a table in the query. このテーブルには、別のテーブル内の列にアクセスする式と関数の組み合わせで計算される、計算列があります。This table has computed columns that are computed by a combination of expressions and functions that access columns in another table. 式と関数で参照されるテーブルが、アクセスされるときに NOLOCK テーブル ヒントを使用することはありません。The tables referenced by the expressions and functions do not use the NOLOCK table hint when accessed.

SQL ServerSQL Server では、FROM 句内の各テーブルに対して、次の各グループの複数のテーブル ヒントが許可されません。does not allow for more than one table hint from each of the following groups for each table in the FROM clause:

  • 粒度ヒント:PAGLOCK、NOLOCK、READCOMMITTEDLOCK、ROWLOCK、TABLOCK、または TABLOCKX。Granularity hints: PAGLOCK, NOLOCK, READCOMMITTEDLOCK, ROWLOCK, TABLOCK, or TABLOCKX.
  • 分離レベル ヒント:HOLDLOCK、NOLOCK、READCOMMITTED、REPEATABLEREAD、SERIALIZABLE。Isolation level hints: HOLDLOCK, NOLOCK, READCOMMITTED, REPEATABLEREAD, SERIALIZABLE.

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

フィルター選択されたインデックスをテーブル ヒントとして使用できますが、クエリで選択する行のすべてがカバーされているわけではない場合、クエリ オプティマイザーからエラー 8622 が返されます。A filtered index can be used as a table hint, but will cause the query optimizer to generate error 8622 if it does not cover all of the rows that the query selects. フィルター選択されたインデックス ヒントが無効になる例を次に示します。The following is an example of an invalid filtered index hint. この例では、フィルター選択されたインデックス FIBillOfMaterialsWithComponentID を作成し、SELECT ステートメントのインデックス ヒントとして使用します。The example creates the filtered index FIBillOfMaterialsWithComponentID and then uses it as an index hint for a SELECT statement. フィルター選択されたインデックスの述語には、ComponentID が 533、324、および 753 のデータ行が含まれています。The filtered index predicate includes data rows for ComponentIDs 533, 324, and 753. クエリ述語にも ComponentID が 533、324、および 753 のデータ行が含まれていますが、フィルター選択されたインデックスには存在しない ComponentID 855 および 924 も結果セットに含めるよう拡張されています。The query predicate also includes data rows for ComponentIDs 533, 324, and 753 but extends the result set to include ComponentIDs 855 and 924, which are not in the filtered index. したがって、クエリ オプティマイザーはフィルター選択されたインデックス ヒントを使用できず、エラー 8622 が生成されます。Therefore, the query optimizer cannot use the filtered index hint and generates error 8622. 詳細については、「 Create Filtered Indexes」を参照してください。For more information, see 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 オプションにない場合、クエリ オプティマイザーはインデックス ヒントを無視します。The query optimizer will not consider an index hint if the SET options do not have the required values for filtered indexes. 詳細については、「CREATE INDEX (Transact-SQL)」を参照してください。For more information, see CREATE INDEX (Transact-SQL).

NOEXPAND の使用Using NOEXPAND

NOEXPAND はインデックス付きビューにのみ適用できます。NOEXPAND applies only to indexed views. インデックス付きビューとは、一意なクラスター化インデックスが作成されているビューを示します。An indexed view is a view with a unique clustered index created on it. インデックス付きビューおよびベース テーブルの両方に存在する列への参照がクエリに含まれていて、クエリ オプティマイザーがクエリの実行にインデックス付きビューを使用する方が最適であると判断した場合、クエリ オプティマイザーはビューのインデックスを利用します。If a query contains references to columns that are present both in an indexed view and base tables, and the query optimizer determines that using the indexed view provides the best method for executing the query, the query optimizer uses the index on the view. この機能は、インデックス付きビューのマッチングと呼ばれます。This functionality is called indexed view matching. SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP1 より前のバージョンでは、SQL ServerSQL Server の特定のエディションでのみ、クエリ オプティマイザーではインデックス付きビューが自動的に使用されます。Prior to SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP1, automatic use of an indexed view by the query optimizer is supported only in specific editions of SQL ServerSQL Server. SQL ServerSQL Serverの各エディションでサポートされる機能の一覧については、「 SQL Server 2016 の各エディションがサポートする機能」を参照してください。For a list of features that are supported by the editions of SQL ServerSQL Server, see Features Supported by the Editions of SQL Server 2016.

ただし、オプティマイザーで、インデックス付きビューのマッチングを検討したり、NOEXPAND ヒントで参照されるインデックス付きビューを使用したりするには、以下の SET オプションを ON に設定する必要があります。However, for the optimizer to consider indexed views for matching, or use an indexed view that is referenced with the NOEXPAND hint, the following SET options must be set to ON.

注意

Azure SQL データベースAzure SQL Database では、NOEXPAND ヒントを指定しなくても、自動的なインデックス付きビューの使用がサポートされます。supports automatic use of indexed views without specifying the NOEXPAND hint.

ANSI_NULLSANSI_NULLS ANSI_WARNINGSANSI_WARNINGS CONCAT_NULL_YIELDS_NULLCONCAT_NULL_YIELDS_NULL
ANSI_PADDINGANSI_PADDING ARITHABORT1ARITHABORT1 QUOTED_IDENTIFIERQUOTED_IDENTIFIER

1 ARITHABORT は、ANSI_WARNINGS が ON に設定されている場合は、暗黙的に ON に設定されます。1 ARITHABORT is implicitly set to ON when ANSI_WARNINGS is set to ON. したがって、この設定を手動で調整する必要はありません。Therefore, you do not have to manually adjust this setting.

また、NUMERIC_ROUNDABORT オプションは OFF に設定する必要があります。Also, the NUMERIC_ROUNDABORT option must be set to OFF.

オプティマイザーがインデックス付きビューのインデックスを使用するように強制するには、NOEXPAND オプションを指定します。To force the optimizer to use an index for an indexed view, specify the NOEXPAND option. このヒントは、ビューがクエリ内でも指定されている場合にのみ使用できます。This hint can be used only if the view is also named in the query. SQL ServerSQL Server では、FROM 句で直接ビューを指定していないクエリで、特定のインデックス付きビューが使用されるようにするヒントは用意されていません。しかし、クエリ オプティマイザーでは、インデックス付きビューがクエリで直接参照されていなくても、その使用が検討されます。does not provide a hint to force a particular indexed view to be used in a query that does not name the view directly in the FROM clause; however, the query optimizer considers using indexed views, even if they are not referenced directly in the query. NOEXPAND テーブル ヒントを使用すると、SQL Server はインデックス付きビューに対してのみ自動的に統計を作成します。SQL Server will only automatically create statistics on an indexed view when a NOEXPAND table hint is used. このヒントを省略すると、統計を手動で作成することでは解決できない、統計がないことに関する実行プランの警告につながる場合があります。Omitting this hint can lead to execution plan warnings about missing statistics that cannot be resolved by creating statistics manually. クエリの最適化中、SQL ServerSQL Server は、クエリがビューを直接参照し、NOEXPAND ヒントが使用されるときに、自動的または手動で作成された統計情報の表示を使用します。During query optimization SQL ServerSQL Server will use view statistics that were created automatically or manually when the query references the view directly and the NOEXPAND hint is used.

クエリ ヒントとしてのテーブル ヒントの使用Using a Table Hint as a Query Hint

OPTION (TABLE HINT) 句を使用すると、テーブル ヒントをクエリ ヒントとして指定することもできます。Table hints can also be specified as a query hint by using the OPTION (TABLE HINT) clause. プラン ガイドのコンテキスト内でのみ、テーブル ヒントをクエリ ヒントとして使用することをお勧めします。We recommend using a table hint as a query hint only in the context of a plan guide. アドホック クエリに対しては、これらのヒントをテーブル ヒントとしてのみ指定します。For ad-hoc queries, specify these hints only as table hints. 詳細については、「クエリ ヒント (Transact-SQL)」を参照してください。For more information, see Query Hints (Transact-SQL).

アクセス許可Permissions

KEEPIDENTITY、IGNORE_CONSTRAINTS、IGNORE_TRIGGERS の各ヒントには、テーブルに対する ALTER 権限が必要です。The KEEPIDENTITY, IGNORE_CONSTRAINTS, and IGNORE_TRIGGERS hints require ALTER permissions on the table.

使用例Examples

A.A. TABLOCK ヒントを使用してロック手法を指定するUsing the TABLOCK hint to specify a locking method

次の例では、AdventureWorks2012AdventureWorks2012 データベース内の Production.Product テーブルに対して共有ロックを使用することと、このロックを UPDATE ステートメントの終了まで保持することを指定します。The following example specifies that a shared lock is taken on the Production.Product table in the AdventureWorks2012AdventureWorks2012 database and is held until the end of the UPDATE statement.

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

B.B. FORCESEEK ヒントを使用したインデックスのシーク操作の指定Using the FORCESEEK hint to specify an index seek operation

次の例では、インデックスを指定せずに FORCESEEK ヒントを使用して、AdventureWorks2012AdventureWorks2012 データベース内の Sales.SalesOrderDetail テーブルに対するインデックスのシーク操作を実行するようにクエリ オプティマイザーを設定します。The following example uses the FORCESEEK hint without specifying an index to force the query optimizer to perform an index seek operation on the Sales.SalesOrderDetail table in the AdventureWorks2012AdventureWorks2012 database.

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 ヒントを使用して、指定したインデックスおよびインデックス列に対してインデックスのシーク操作を実行するようにクエリ オプティマイザーを設定します。The following example uses the FORCESEEK hint with an index to force the query optimizer to perform an index seek operation on the specified index and index column.

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.C. FORCESCAN ヒントを使用してインデックスのスキャン操作を指定するUsing the FORCESCAN hint to specify an index scan operation

次の例では、FORCESCAN ヒントを使用して、AdventureWorks2012AdventureWorks2012 データベース内の Sales.SalesOrderDetail テーブルに対するスキャン操作を実行するようにクエリ オプティマイザーを設定します。The following example uses the FORCESCAN hint to force the query optimizer to perform a scan operation on the Sales.SalesOrderDetail table in the AdventureWorks2012AdventureWorks2012 database.

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);  

参照See Also

OPENROWSET (Transact-SQL) OPENROWSET (Transact-SQL)
Hints (Transact-SQL) Hints (Transact-SQL)
クエリ ヒント (Transact-SQL)Query Hints (Transact-SQL)