私はmsdnでいくつかのドキュメントを回っていましたが、「現在のトランザクションによって読み取られたデータを他のトランザクションが変更するのを防ぐために共有ロックは発行されていません」と書かれていました。
したがって、素人の用語(つまり私の)では、これはダーティリードの問題を引き起こします。危険すぎるのはどれですか?
それが使用される実際のシナリオを知っている人はいますか。
私はmsdnでいくつかのドキュメントを回っていましたが、「現在のトランザクションによって読み取られたデータを他のトランザクションが変更するのを防ぐために共有ロックは発行されていません」と書かれていました。
したがって、素人の用語(つまり私の)では、これはダーティリードの問題を引き起こします。危険すぎるのはどれですか?
それが使用される実際のシナリオを知っている人はいますか。
挿入と更新のみが行われるキューを保持するテーブルがあります。何も削除されません。行には、関連するプロセスで何が起こっているかを示すさまざまなフラグがあります。本番システムでは行ロックのみが使用されますが、一度に数十個がさまざまな行で保持されるため、さまざまなプロセスが一度に発生する可能性があります。
システムの過負荷を避けるために、処理中のアイテムの数を確認します。ユーザーが新しいプロセスを起動すると、現在キューで処理されているアイテムが 10 未満になるまで、サブプロセスの生成を待機します。
自分のステータスを更新する必要がある可能性のあるプロセスでロックを取得しないようにする必要があり、ロックされたアイテムのステータスを確認する必要があります。キューで何が起こっているかを確認するのを待つのを防ぎ、まだ完了としてマークされていないアイテムの数をカウントするために使用with (nolock)
します。これは、プロセスが完了したときにのみ発生することがロジックによって保証されています。
すべてのデータが同じように作成されるわけではありません。かなりの量のデータは実際には重要ではないため、状況によっては、ダーティ リードが行われても問題ありません。たとえば、バッチ プロセスでは、多数の異なるテーブルを一括更新できます。ユーザーのメッセージの読み取り数を読み取ることができます。ロックが使用可能になるまでユーザーが数秒、数分、または数時間待たなければならないよりも、数が 1 または 2 ずれている方が望ましいでしょう。
言い換えれば、正確なデータが実際には必要ないときに同時実行性を高めており、(潜在的に) 無効なデータがあっても問題ありません。
通常、これを使用して、通常はログに使用する比較的忙しいテーブルをクエリします。
SELECT TOP 10 * FROM dbo.MessageLog (NOLOCK) WHERE AppCode = 'DesktopApp' ORDER BY MessageDate DESC
テーブルのレコードは主に 1 回書き込まれ、更新されることはありません。
一部のレコードが古くなっている可能性があることを受け入れる意思がある場合、状況によっては、より高速なアクセスを提供できます。
例えば:
SELECT COUNT(*) FROM mytable (nolock)
より少ないリソースを使用し、一般的に大きなテーブルではより高速です
SELECT COUNT(*) FROM mytable
読み取りが多く、書き込みが少ないテーブルで使用します。接続がデータを読み取るだけの場合、これは多くの場合、ダーティ リードを実行しても危険ではありません。これにより、テーブルでのブロックが防止され、パフォーマンスが向上します。
nolockの詳細と、それが良い/悪い場合については、https: //stackoverflow.com/a/1453000/1038940 をご覧ください。
あなたは明らかに天才です。絶対に使用しないでください。
NOLOCK は、データベースの読み取りを高速化するための魔法の方法として悪用されることがよくありますが、私はできる限り使用しないようにしています。
結果セットには、まだコミットされていない行が含まれる場合があり、後でロールバックされることがよくあります。
エラーまたは結果セットは、空であるか、行が欠落しているか、同じ行が複数回表示されている可能性があります。
これは、他のトランザクションが、データの読み取りと同時にデータを移動しているためです。
READ COMMITTED は、複数のユーザーが同じセルを同時に変更する単一の列内でデータが破損するという問題を追加します。
他にも副作用があり、最初に得たいと思っていた速度の増加が犠牲になります.
わかったので、絶対に使用しないでください。
私たちにとっては非常に簡単です - 非金融 (そして通常はめったに変更されない) データ (顧客の住所、商品の説明、さまざまな設定オプションなど) を nolock ヒントでフェッチし、金融または定量データ (価格や残高など) を「通常の」ロックでフェッチします。