私は簡単な質問から始めます：
Wikipedia およびMsdnの Dirty Read の定義によると 、次のようになります。
T1 と T2 の 2 つの同時トランザクションがあります。
T1 が行を更新しており、T2 が T1 によって「まだコミットされていない」行を読み取っている場合、ダーティ リードが発生します。
ただし、Read Committed レベルでは、データが読み取られるとすぐに共有ロックが解放されます (トランザクションの終了時やステートメントの終了時でさえありません)。
では、Read Committed はどのようにダーティ リードを防止するのでしょうか? Bkaz 更新された行 T2 で解放された共有ロックが更新された行を読み取ることができ、t1 が操作全体をロールバックできるようになるとすぐに、t1 の手でダーティ リードが発生します。
T1 が行をロックしているため、ダーティ リードが防止されます。そのため、T2 は後でロールバックできる「まだコミットされていない」行を読み取ることができません。
Read Committed が解決しようとしている問題は次のとおりです。
T1 はトランザクションを作成し、何かを書き込みます
T2は何かを読みます
T1 トランザクションのロールバック
現在、T2 には実際には存在しなかったデータがあります。
DB の構造に応じて、2 つの「適切な」可能性があります。
T1 はトランザクションを作成し、何かを書き込みます
T2 は T1 がトランザクションを終了するのを待ちます
また
T2 は、T1 がトランザクションを開始する前の DB の「スナップショット」を読み取ります (これは、行のバージョン管理を使用してコミットされた読み取りと呼ばれます)。
(MSSQL のデフォルトは最初のオプションです)
たとえば、さまざまな分離レベルの比較があります: http://msdn.microsoft.com/en-us/library/ms345124(SQL.90).aspx (SQL Server 2005 で提供される分離レベルを参照)
SQL Serverは、読み取りコミット分離レベルでステートメントを実行すると、行ごとに短期間の共有ロックを取得します。これらの共有ロックの期間は、各行を読み取って処理するのに十分な長さです。サーバーは通常、次の行に進む前に各ロックを解放します。したがって、読み取りコミットの下で単純なselectステートメントを実行し、ロックをチェックする場合（たとえば、sys.dm_tran_locksを使用）、通常、一度に最大で1つの行ロックが表示されます。これらのロックの唯一の目的は、ステートメントがコミットされたデータのみを読み取って返すようにすることです。更新は常に排他ロックを取得し、共有ロックを取得しようとするリーダーをブロックするため、ロックは機能します。
ここからリッピング