READ UNCOMMITTED分離レベルを使用する理由は何ですか? 質問する

この分離レベルでは、ダーティ リードが許可されます。あるトランザクションは、他のトランザクションによって行われたコミットされていない変更を参照する場合があります。

最高レベルの分離を維持するために、DBMS は通常、データのロックを取得しますが、その結果、同時実行性が失われ、ロックのオーバーヘッドが大きくなる可能性があります。この分離レベルでは、この特性が緩和されます。

いくつかの例とさらに詳しい情報については、Wikipedia の記事をREAD UNCOMMITTED参照してください。

また、Stack Overflow の初期に Jeff Atwood 氏と彼のチームがデッドロック問題に取り組んだ方法についてのブログ記事もご覧ください。Jeff 氏によると:

しかし、 はnolock危険ですか?オンにすると無効なデータを読み取ってしまう可能性がありますかread uncommitted? 理論上はそうです。 を試してみたいと言うと、ACID サイエンスを披露し、建物の火災警報を鳴らすようなデータベース アーキテクチャの専門家がたくさんいますnolock。 理論は怖いのは事実です。しかし、私の考えはこうです。「理論上は、理論と実践の間に違いはありません。しかし、実際には違いがあります。」

データベースのデッドロック問題が発生した場合、一般的な「問題解決に効く」怪しげな解決策としてこれを使用することは決してお勧めしませんnolock。まずは問題の原因を診断するようにしてください。

しかし、実際には、nolock単純で簡単な読み取り専用処理であることが確実にわかっているクエリに追加しても、問題が発生することはないようです...何をしているのかわかっている限りは。

レベルに代わる選択肢としてREAD UNCOMMITTED検討したいのが ですREAD COMMITTED SNAPSHOT。再び Jeff の言葉を引用します。

スナップショットは、まったく新しいデータ変更追跡方法に依存しています。わずかな論理的変更だけではなく、サーバーがデータを物理的に異なる方法で処理する必要があります。この新しいデータ変更追跡方法を有効にすると、すべてのデータ変更のコピー、つまりスナップショットが作成されます。競合時にライブ データではなくこれらのスナップショットを読み取ることで、読み取り時に共有ロックが不要になり、データベース全体のパフォーマンスが向上する可能性があります。