分離レベルとアノマリー対応表

対応表を「原理」で読む

分離レベルの一覧表（→ トランザクション分離レベル）は暗記対象になりがちですが、表の各マスがなぜ「防ぐ／起きうる」になるのかは、異常の定義と各レベルがいつ・何を見るかから決まります。ここではマスの根拠を分解し、規格表に載らない Write Skew まで含めた原理レベルの対応関係を整理します。

要点を先に置きます。第一に、SQL標準の表は3つの異常（Dirty Read・Non-Repeatable Read・Phantom）だけを基準にした最低保証であり、実装の実力ではありません。第二に、MVCC のスナップショット分離はこの3異常を全て防ぐのに Write Skew を防げず、規格の4レベルとは別軸にあります。

アノマリーの定義（境界条件）

各異常は「2回のアクセスの間に、他のトランザクションの何が割り込むか」で区別されます。定義が曖昧だと表も読めないので、まず境界を固定します。

Non-Repeatable Read と Phantom の違いは「既存の1行の値が変わる」か「条件にヒットする行の集合が変わる」かです。前者は行ロックや行単位のバージョンで塞げますが、後者は「まだ存在しない行」が相手なので、範囲を覆う仕組み（次節）が要ります。

なぜそのマスになるか：レベル別の根拠

SQL標準の4レベルが各マスで「防ぐ／起きうる」になる理由は、そのレベルがコミット済みしか読まないか、読み取りの一貫点をいつ固定するか、範囲をロックするかの3点で説明できます。

• READ UNCOMMITTED: 未コミットの版も読めるため Dirty Read が起きうる。最も緩い。
• READ COMMITTED: 各文の実行時点で確定済みだけを読むので Dirty Read は消える。だが一貫点が文ごとに更新されるため、再読すると別の確定版を見て Non-Repeatable Read が残る。
• REPEATABLE READ: 一貫点をトランザクション開始時に固定するので、既存行の再読はブレず Non-Repeatable Read まで防ぐ。規格上は範囲を保護しないので Phantom は残りうる。
• SERIALIZABLE: 結果が何らかの直列実行と等価になることを保証し、Phantom を含む全異常を防ぐ。

READ COMMITTED   : 一貫点 = 文ごとに取り直す  -> 再読で値が動く
REPEATABLE READ  : 一貫点 = Tx開始時に固定      -> 既存行の再読は安定
SERIALIZABLE     : 直列化可能を保証            -> 範囲・順序まで含めて安全

つまり「いつスナップショット（一貫点）を取り直すか」がそのまま Dirty/Non-Repeatable の境界を決め、「範囲まで守るか」が Phantom の境界を決めます（→ MVCC の内部実装）。

規格表（最低保証）

ここまでの根拠を SQL標準の最低保証としてまとめると、おなじみの表になります。重要なのは、これが「ここまでは必ず防ぐ」という下限だという点です。

別軸の罠：スナップショット分離と Write Skew

ここからが上級の本題です。多くの MVCC 実装の REPEATABLE READ はスナップショット分離 (SI) で、トランザクション開始時の一枚のスナップショットを読み続けます。SI は規格の3異常を全て防ぎますが、規格の4レベルとは別系統の保証で、Write Skew という異常を防げません。

Write Skew は「各トランザクションが同じ集合を読み、その読みに基づいて互いに異なる行を書く」ときに起きます。書く対象が重ならないので書き込み衝突として検知されず、しかし合算すると不変条件が壊れます。

不変条件: オンコール医は常に1名以上いること（現在2名: AliceとBob）

Tx1: SELECT count(*) FROM doctors WHERE on_call;  -- 2 を読む -> 1名残る判断
     UPDATE doctors SET on_call=false WHERE name='Alice';
Tx2: SELECT count(*) FROM doctors WHERE on_call;  -- 2 を読む -> 1名残る判断
     UPDATE doctors SET on_call=false WHERE name='Bob';

両者ともスナップショットでは「自分が降りても相手が残る」と見える。
書く行は別（Alice と Bob）なので衝突せず両方コミット成功。
結果: オンコール 0 名 -> 不変条件が破れる。

各トランザクションは単独では完全に正しく、Dirty/Non-Repeatable/Phantom のどれにも該当しません。それでも整合性が壊れるのは、読んだ前提（相手が残る）が、相手の書き込みで覆されたのに検知されないからです。SI が「読み取りスナップショットの一貫性」しか保証せず、「読みと書きの間の論理的依存」を見ていないことが根因です。

拡張対応表：Write Skew を加える

規格の3異常に Write Skew を足し、代表的な実装の実際の挙動を並べると、対応関係が立体的になります。

PostgreSQL の SERIALIZABLE は SSI（直列化可能スナップショット分離） で、SI に「読み書き依存の追跡」を足し、直列化を壊しうる危険な依存の交差を検出したトランザクションを中断します。ロックを増やさず楽観的に検知する方式のため、競合時はシリアライズ失敗が返り、アプリ側はリトライ前提で書く必要があります（→ ロックと MVCC）。

Write Skew を SERIALIZABLE 無しで塞ぐ

SERIALIZABLE の中断・再試行コストを避けたい場合、読んだ前提を明示的にロックして「読みと書きの依存」を物理化できます。

-- 読んだ集合に書き込み意図のロックを掛け、相手を待たせる
SELECT count(*) FROM doctors
  WHERE on_call FOR UPDATE;   -- 読んだ行を更新ロック
-- ここで相手はブロックされ、片方ずつ直列化される
UPDATE doctors SET on_call=false WHERE name='Alice';

SELECT ... FOR UPDATE は読んだ既存行を更新ロックし、相手の更新を待たせます。ただし「まだ存在しない行」が前提に絡む場合（挿入による Write Skew）は、行ロックでは覆えず、範囲を覆う仕組みか一意制約などの宣言的制約が必要です。どこまでがロックで塞げ、どこからが SERIALIZABLE 必須かは、前提が「既存行」か「行の不在」かで分かれます。

まとめ

• 規格の対応表は Dirty/Non-Repeatable/Phantom の3異常に対する最低保証で、境界は「一貫点をいつ取るか」「範囲を守るか」で決まる。
• 実装は規格より強いことが多く、多くの MVCC の REPEATABLE READ は SI として Phantom まで実質防ぐ。
• SI は規格の3異常を防ぐが Write Skew を防げない。読んだ前提が相手の別行への書き込みで覆されても検知されないため。
• Write Skew を塞ぐのは SERIALIZABLE（PostgreSQL は SSI で楽観検知、リトライ前提）か、SELECT ... FOR UPDATE 等での明示ロック。ただし行の不在が前提なら範囲保護が要る。

分離レベルの正しさは ACID の I（独立性）の度合いそのものです。表のマスを暗記するのではなく、各異常の成立条件と実装が見るスナップショットの粒度から、対応関係を都度導けるようにしておくのが上級者の読み方です。