分離レベル：見え方が段階で変わる
同じ read/write の操作列でも、トランザクション分離レベルを上げるほど、見える異常（ダーティリード・ノンリピータブルリード・ファントム）が段階的に消えていきます。
分離レベル（弱い → 強い）
操作シナリオ（2つのトランザクション T1・T2 の操作列）
6 / 6
分離レベル
—
T1 の DB 値（確定値）
—
T2 が今 read した値
—
この操作列の判定
—
この分離レベルで起こりうる異常
操作タイムライン（左 T1 ／ 右 T2、上から時間が進む）
複数のトランザクションが同時に同じデータを触ると、「他人の途中の書き込みが見えてしまう」「同じ行を二度読むと値が変わる」などの読み取り異常が起こり得ます。
SQL 標準は READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE の 4 段階を定め、上に行くほど多くの異常を禁止します。同じ操作列でも、レベルを切り替えると T2 に見える値が変わります。
上のボタンで分離レベルとシナリオを切り替え、スライダーでタイムラインを進めて、T2 が「いつ・何を読むか」を確かめましょう。
SQL 標準は READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE の 4 段階を定め、上に行くほど多くの異常を禁止します。同じ操作列でも、レベルを切り替えると T2 に見える値が変わります。
上のボタンで分離レベルとシナリオを切り替え、スライダーでタイムラインを進めて、T2 が「いつ・何を読むか」を確かめましょう。
いま何が起きている？
ここがポイント
- 同じ操作列でも結果が変わる ── 異常が起こるかどうかは分離レベル次第。アプリのバグに見えて実は設定の問題、というのが典型。
- レベルは異常の禁止リスト ── READ COMMITTED は未確定値を、REPEATABLE READ は再読込のズレを、SERIALIZABLE はファントムまで禁止する。
- 強いほど安全だが遅くなりがち ── ロックや MVCC のコストが増え、競合時の待ち・ロールバックが起きやすい。要件に対して必要十分なレベルを選ぶ。
- 標準は「最低保証」 ── 実 DB の実装はこれより強いことがある（例: PostgreSQL の REPEATABLE READ はスナップショットでファントムもほぼ防ぐ）。