本当の質問は次のとおりだと思います。
ダーティ リードを気にしない場合、with (NOLOCK)ヒントを SELECT ステートメントに追加すると、次のパフォーマンスに影響します。
- 現在の SELECT ステートメント
- 指定されたテーブルに対する他のトランザクション
例:
Select *
from aTable with (NOLOCK)
本当の質問は次のとおりだと思います。
ダーティ リードを気にしない場合、with (NOLOCK)ヒントを SELECT ステートメントに追加すると、次のパフォーマンスに影響します。
例:
Select *
from aTable with (NOLOCK)
1)はい、 で選択するNOLOCK
と、通常の選択よりも速く完了します。
2)はい、select withNOLOCK
を使用すると、影響を受けるテーブルに対する他のクエリを通常の select よりも速く完了できます。
これはなぜでしょうか?
NOLOCK
通常 (DB エンジンによって異なります) は、データを提供することを意味します。データがどのような状態にあるかは気にしません。これは、より高速で、リソースの消費が少なく、非常に危険です。
システムの重要な部分からの更新や実行を絶対に行わないように警告する必要があります。また、NOLOCK
読み取りに由来するデータを使用して絶対的な正確性が必要な場合も注意してください。このデータには、クエリの実行中に削除された行、またはまだファイナライズされていない他のセッションで削除された行が含まれている可能性があります。このデータには、部分的に更新された行が含まれている可能性があります。このデータには、外部キー制約に違反するレコードが含まれている可能性があります。このデータは、テーブルに追加されたがまだコミットされていない行を除外する可能性があります。
データの状態を知る方法は本当にありません。
ある程度の誤差が許容される行数やその他の要約データなどを取得しようとしている場合はNOLOCK
、これらのクエリのパフォーマンスを向上させ、データベースのパフォーマンスに悪影響を与えないようにするための良い方法です。
常に細心のNOLOCK
注意を払ってヒントを使用し、疑わしいデータを返すようにしてください。
NOLOCK を使用すると、共有ロックがないため、ほとんどの SELECT ステートメントが高速になります。また、ロックの発行がないということは、ライターが SELECT によって妨げられないことを意味します。
NOLOCK は、READ UNCOMMITTED の分離レベルと機能的に同等です。主な違いは、選択した場合、一部のテーブルでは NOLOCK を使用でき、他のテーブルでは使用できないことです。複雑なクエリですべてのテーブルに NOLOCK を使用する場合は、すべてのテーブルにヒントを適用する必要がないため、SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED を使用する方が簡単です。
ここでは、自由に使用できるすべての分離レベルに関する情報と、表のヒントを示します。
上記の内容に加えて、nolock を使用すると、select の前にコミットされた行を取得できないというリスクが実際に課されることを十分に認識しておく必要があります。
http://blogs.msdn.com/sqlcat/archive/2007/02/01/previously-committed-rows-might-be-missed-if-nolock-hint-is-used.aspxを参照してください。
ロックを待つ必要がないため、高速になります
クエリが一度に複数回実行される場合、各トランザクションは他のトランザクションが完了するのを待つ必要がないため、答えは [はい]です。ただし、クエリが単独で 1 回実行される場合、答えは No です。
はい。WITH(NOLOCK) を慎重に使用すると、データベース全体が高速化される可能性が高くなります。これは、他のトランザクションがこの SELECT ステートメントの終了を待つ必要がないことを意味しますが、その一方で、他のトランザクションは処理時間を新しいトランザクションと共有しているため、速度が低下します。
クラスター化インデックスを持つテーブルの SELECT ステートメントでのみ使用するように注意してください。WITH (NOLOCK)
WITH(NOLOCK) は、データベースの読み取りトランザクションを高速化する魔法の方法としてよく利用されます。
結果セットには、まだコミットされていない行が含まれる場合があり、後でロールバックされることがよくあります。
WITH(NOLOCK) がクラスター化されていないインデックスを持つテーブルに適用された場合、行データが結果テーブルにストリーミングされるときに、他のトランザクションによって行インデックスが変更される可能性があります。これは、結果セットに行がないか、同じ行が複数回表示される可能性があることを意味します。
READ COMMITTED は、複数のユーザーが同じセルを同時に変更する単一の列内でデータが破損するという問題を追加します。