この分離レベルにより、ダーティ読み取りが可能になります。あるトランザクションでは、他のトランザクションによって行われたコミットされていない変更が表示される場合があります。
最高レベルの分離を維持するために、DBMSは通常、データのロックを取得します。これにより、同時実行性が失われ、ロックのオーバーヘッドが高くなる可能性があります。この分離レベルは、このプロパティを緩和します。
READ UNCOMMITTEDに関するウィキペディアの記事を確認することをお勧めします。 いくつかの例とさらなる読み物のために。
また、StackOverflowの初期の頃に彼と彼のチームがデッドロックの問題にどのように取り組んだかについてのJeffAtwoodのブログ記事をチェックすることにも興味があるかもしれません。ジェフによると：
しかし、
nolock危険ですか？read uncommittedで無効なデータを読み取ってしまう可能性があります の上？はい、理論的には。 ACIDサイエンスを開始し、nolockを試してみたいと言ったときに、建物の火災警報器を鳴らしているデータベースアーキテクチャの宇宙飛行士が不足することはありません。 。それは本当です：理論は怖いです。しかし、私が思うのは、「理論的には理論と実践の間に違いはありません。実際には違いがあります。」
nolockの使用は絶対にお勧めしません あなたが抱えているかもしれないデータベースのデッドロックの問題に対する一般的な「あなたを苦しめるものに良い」スネークオイルの修正として。最初に問題の原因を診断する必要があります。ただし、実際には
nolockを追加します 絶対に知っているクエリに対して、単純でわかりやすい読み取り専用の問題が問題につながることは決してないようです...自分が何をしているのかを知っている限り。
READ UNCOMMITTEDの代替案 検討したいレベルは、READ COMMITTED SNAPSHOTです。 。ジェフをもう一度引用する：
スナップショットは、まったく新しいデータ変更追跡方法に依存しています...単なるわずかな論理的変更ではなく、サーバーがデータを物理的に異なる方法で処理する必要があります。この新しいデータ変更追跡方法を有効にすると、すべてのデータ変更のコピーまたはスナップショットが作成されます。 競合時にライブデータではなくこれらのスナップショットを読み取ることにより、読み取り時に共有ロックが不要になり、データベース全体のパフォーマンスが向上する可能性があります。