SELECTステートメントでのNOLOCKヒントの効果
https://stackoverflow.com/questions/210171
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
本当の質問は：
ダーティリードを気にしない場合、 with（NOLOCK）ヒントをSELECTステートメントに追加すると、次のパフォーマンスに影響します。
- 現在のSELECTステートメント
- 指定されたテーブルに対する他のトランザクション
例：
Select *
from aTable with (NOLOCK)
解決
1）はい、 NOLOCK を使用した選択は、通常の選択よりも速く完了します。
2）はい、 NOLOCK を使用した選択では、影響を受けるテーブルに対する他のクエリが通常の選択よりも速く完了することができます。
これはなぜですか？
NOLOCK は、通常（DBエンジンによって異なります）、データを提供することを意味します。データの状態は気にしません。また、読み取り中にデータを保持する必要はありません。 。すべてが同時に高速になり、リソースの消費量が少なく、非常に危険です。
システムの重要なものから更新を実行したり、システムの重要なものを実行したりしないように、または NOLOCK 読み取りからのデータを使用して絶対的な正確性が必要な場合このデータに、クエリの実行中に削除された行、またはまだファイナライズされていない他のセッションで削除された行が含まれている可能性があります。このデータには、部分的に更新された行が含まれている可能性があります。このデータには、外部キーの制約に違反するレコードが含まれている可能性があります。このデータは、テーブルに追加されたがまだコミットされていない行を除外する可能性があります。
データの状態を知る方法は本当にありません。
エラーのマージンを許容できる行数やその他の要約データなどを取得しようとしている場合、 NOLOCK はこれらのクエリのパフォーマンスを向上させ、それらを持たないようにする良い方法ですデータベースのパフォーマンスに悪影響を及ぼします。
NOLOCK ヒントは常に慎重に使用し、返されるデータは疑わしく処理してください。
他のヒント
NOLOCKは、共有ロックがないため、ほとんどのSELECTステートメントを高速化します。また、ロックの発行がないため、ライターがSELECTによって妨げられることはありません。
NOLOCKは、READ UNCOMMITTEDの分離レベルと機能的に同等です。主な違いは、選択した場合、一部のテーブルではNOLOCKを使用できますが、他のテーブルでは使用できないことです。複雑なクエリのすべてのテーブルでNOLOCKを使用する場合、すべてのテーブルにヒントを適用する必要がないため、SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDの使用が簡単です。
ここでは、使用可能なすべての分離レベルに関する情報と、テーブルヒントを示します。
上記の説明に加えて、nolockは実際には、選択の前にコミットされた行を 取得しないというリスクを強いることに注意する必要があります。
ロックを待つ必要がないため、高速になります
-
待機する必要がないため、現在のSELECTは早く開始されます。
-
他のトランザクションは処理時間を新しいトランザクションと共有しているため、速度が低下します。
使用しないでください。
NOLOCKは、データベースの読み込みを高速化する魔法の方法として悪用されることがよくありますが、可能な限り使用しないようにしています。
結果セットには、まだコミットされていない行が含まれることがあり、多くの場合、後でロールバックされます。
エラーまたは結果セットは空であるか、行が欠落しているか、同じ行を複数回表示する可能性があります。
これは、他のトランザクションが読み取りと同時にデータを移動しているためです。
READ COMMITTEDは、複数のユーザーが同じセルを同時に変更する単一の列内でデータが破損するという追加の問題を追加します。
他にも副作用があり、そもそも得たいと思っていた速度の増加を犠牲にします。
ご存知のとおり、二度と使用しないでください。
