ファントムと述語ロック・ギャップロック・next-keyロック

ファントムは行ロックでは防げない

ファントムリード（phantom read）とは、同一トランザクション内で同じ範囲述語のクエリを2回実行したら、2回目に行が増減している現象です。たとえば SELECT ... WHERE age BETWEEN 20 AND 30 を2回走らせる間に、別トランザクションが age = 25 の行を挿入してコミットすると、1回目には無かった行が2回目に現れます。

ここが本質的に難しいのは、まだ存在しない行をロックできない点です。読み取りロック（共有ロック）は「いま存在する行」にしか掛けられません。最初の検索時に該当行を全部ロックしても、age = 25 の行はその時点で存在しないのでロック対象がなく、挿入を止められません。ダーティリードやノンリピータブルリードが既存行の値に対する異常であるのに対し、ファントムは集合の要素数（述語を満たす行の集合）に対する異常です。だから行単位のロックでは構造的に対処できません。

理想解：述語ロック

理論的に正しい解は述語ロック（predicate lock）です。これは個々の行ではなく「age が 20 以上 30 以下」という述語（条件式）そのものをロック対象にします。あるトランザクションがこの述語で読み取りロックを取っているとき、別トランザクションがその述語を満たす行を挿入・更新・削除しようとすると衝突として待たされる、という発想です。存在しない行も「将来その述語を満たすかどうか」で判定するので、ファントムを原理的に封じられます。

問題は実装コストです。挿入を試みるたびに、現在ロック中の全述語に対して「この行はその述語を満たすか」を評価しなければなりません。一般の述語の包含判定（2つの条件が重なるか）は計算が重く、述語が増えるほどコストが膨らみます。

述語ロックの判定（理想）:
  INSERT する行 r について
    for each 保持中の述語ロック P:
      if r が P を満たす:  ロック衝突 → 待機 or デッドロック
  ※ 任意の述語の充足判定は高コスト。実用 RDB はこれをそのまま実装しない

そこで多くの RDB は、述語ロックをインデックス構造の上で近似します。「条件を満たす行が入りうる場所」をインデックスのキー範囲として特定し、その範囲をロックするのです。InnoDB のギャップロックはこの近似の代表例です。なお PostgreSQL の SIREAD ロックも述語ロックの一種ですが、あちらは挿入を待たせずrw-依存を検出して片方を中断する楽観的な実装である点が異なります（→ 直列化可能スナップショット分離(SSI)の検出アルゴリズム）。

InnoDB の3種のロック

InnoDB のロックは、述語ロックを B+木インデックスのキー空間で近似するために設計されています。粒度は次の3つです。

ポイントは、InnoDB のロックがテーブルの行ではなくインデックスのレコードに掛かることです。ロックの範囲はクエリが走査したインデックスのキー順序で決まります。ギャップロックは「隙間」というキー値が存在しない領域への印なので、複数のトランザクションが同じギャップに対するギャップロックを同時に保持できます（互いに共存する）。ギャップロックが衝突するのは「ギャップをロックする側」と「そのギャップに挿入する側」の間だけ、という非対称な設計です。

ギャップロックがファントムを防ぐ原理

具体例で見ます。id に主キー（インデックス）があり、既存値が 10, 20, 30 だとします。あるトランザクション T1 が次を実行したとします。

-- REPEATABLE READ
SELECT * FROM t WHERE id BETWEEN 15 AND 25 FOR UPDATE;

T1 は B+木を走査し、述語 15 以上 25 以下 が指す範囲をカバーするように next-keyロックを掛けます。具体的には、既存行 20 にレコードロックを掛けるだけでなく、その前後のギャップ――(10, 20) と (20, 30) の隙間――にギャップロックを掛けます。

インデックス: ... 10 ──gap── 20 ──gap── 30 ...
T1 が WHERE id BETWEEN 15 AND 25 でロックする範囲:
   (10, 20] = 20 へのレコードロック + (10,20) のギャップ
   (20, 30) = 20 の次のギャップ（上限25を含む隙間）
ここに別 Tx が INSERT id=17 / id=23 しようとすると → ギャップロックで待機

この状態で別トランザクション T2 が INSERT INTO t VALUES (17) を試みると、17 が入るべき隙間 (10, 20) に T1 のギャップロックがあるため、T2 は挿入意図ロック（insert intention lock）の取得で待たされます。23 も同様に (20, 30) で待たされます。結果として、T1 が同じ範囲検索を再実行しても新しい行は現れません。これが存在しない行の挿入を、その行が入る隙間のロックで止めるというファントム防止の中核です。

ロック範囲は検索の走査方法で決まる

next-keyロックの厄介な点は、ロックされる範囲がクエリの述語そのものではなく、実行時にインデックスをどう走査したかで決まることです。述語ロックの「近似」である以上、近似がゆるい方向（広め）に倒れることがあります。

特に重要なのはインデックスが無い検索で、走査が全表に及ぶため、述語が1行しか指していなくても実質テーブル全体のギャップがロックされ、無関係な挿入まで止まります。ロック範囲を述語に近づける――つまりギャップロックを最小化する――には、WHERE 句に効く適切なインデックスを張ることが直接効きます。検索が触れるインデックスのキー範囲が狭いほど、ロックする隙間も狭くなるからです。

デッドロックとの関係・実務上の注意

ギャップロックは挿入を止めるため、複数トランザクションが同じ隙間に対して挿入しようとして待ち合い、デッドロックになりやすい温床でもあります。典型は、2つのトランザクションがそれぞれ範囲検索でギャップを共有保持し（ギャップロックは共存する）、その後それぞれが同じ隙間に挿入しようとして、互いの挿入意図ロックを待つケースです。InnoDB は待ちグラフの閉路を検出して片方を犠牲者としてロールバックします（→ トランザクション分離レベル のロック方式と同じく、デッドロックは2PL系で残る別問題です）。

実務でのポイントを整理します。

• ギャップロックを減らしたいなら適切なインデックスを張る。走査範囲が狭まればロックする隙間も狭まり、並行挿入との衝突とデッドロックが減る。
• READ COMMITTED にすればギャップロックはほぼ消えるが、その代償としてファントムを許容する。挿入競合が激しいワークロードで意図的に選ぶことがある。
• 一意インデックスでの単一行検索はギャップロックを伴わずレコードロックのみに退化することが多く、点指定の更新は範囲ロックを生まない。範囲条件やインデックスの効かない検索が広いロックを生む。
• InnoDB のロックはあくまでインデックス上のキー範囲への印であり、述語ロックの近似である――この前提を押さえると、SHOW ENGINE INNODB STATUS で見える想定外のロック待ちが「どのインデックスのどの隙間か」として読み解ける。

まとめ

• ファントムは述語を満たす行の集合の要素数が変わる異常で、まだ存在しない行を行ロックでは止められない。止めるには述語が指す範囲そのものをロックする必要がある。
• 理想解は述語ロックだが任意述語の充足判定が高コスト。InnoDB はギャップロック（隙間への挿入だけを止める）とnext-keyロック（レコード＋直前ギャップ）で、インデックスのキー範囲として述語ロックを近似する。
• ギャップロックどうしは共存し、衝突するのは挿入側との間だけ。REPEATABLE READ ＋ ロック読み取りでファントムを防ぎ、通常の SELECT は MVCC スナップショットで読む二段構え。
• ロック範囲は実行時の走査方法で決まるため、適切なインデックスでロックを述語に近づけるのが、想定外のロック待ち・デッドロックを避ける王道。