トランザクションと分離レベル — 同時に動く処理が互いをどこまで見てよいか

What — 分離レベルごとに何が起きうるか

分離レベルは「同時に動いている他のトランザクションの作業を、どこまで見てしまうか」の設定です。

4つの分離レベル

A: UPDATE stock = 0    （まだ COMMIT していない）
B: SELECT stock  →  0    ← 見えてしまう
A: ROLLBACK              （なかったことに）

B は存在しなかった値を読んだ = ダーティリード

ダーティリード

コミットされていない変更を読むこと。ロールバックされれば、存在しなかった値を読んだことになる。

ノンリピータブルリード

同じ行を2回読んだら値が変わっていること。間に他のトランザクションがコミットした。

ファントムリード

同じ条件で2回検索したら、行数が変わっていること。他のトランザクションが行を追加・削除した。

ロストアップデート

2つの更新のうち片方が上書きされて消えること。冒頭の事故はこの一種。

楽観ロック

バージョン番号などで、読んでから書くまでに変更されていないことを確認する方式。衝突が稀な場合に向く。

悲観ロック

読む時点で行をロックし、他の処理を待たせる方式（SELECT ... FOR UPDATE）。衝突が頻繁な場合に向く。

Why — なぜ分離レベルという選択肢があるのか

理想を言えば、全部 SERIALIZABLE にすればよいはずです。正しさが最も強いのだから。

しかし SERIALIZABLE は、同時実行の多くを直列化するためスループットが大きく落ちます。秒間1万件の処理が必要なシステムで、全トランザクションを順番待ちさせるわけにはいきません。

そこで「どの異常なら許容できるか」という選択肢が用意されました。

• 集計レポートの数字が、実行中に1件増減しても構わない → READ COMMITTED で十分
• 在庫を引く処理で、二重に引かれるのは絶対に困る → その処理だけ厳しくする

重要なのは、分離レベルが「トランザクション単位で設定できる」ことです。 システム全体を厳しくする必要はなく、危険な処理だけを守ればよい。

分離レベルを上げなくても防げる

冒頭の事故は、分離レベルを上げなくても2つの方法で防げます。

方法1：読む時点でロックする（悲観ロック）

BEGIN;
SELECT stock FROM products WHERE id = ? FOR UPDATE;  -- ← 他の処理を待たせる
-- ここでチェック
UPDATE products SET stock = stock - 1 WHERE id = ?;
COMMIT;

FOR UPDATE を付けると、この行に対する他の FOR UPDATE は待たされます。2つの処理が同時に同じ行を読むこと自体を防ぐわけです。

方法2：更新条件にチェックを含める

UPDATE products SET stock = stock - 1
WHERE id = ? AND stock >= 1;     -- ← 条件をここに入れる

-- 影響行数が 0 なら在庫切れ

UPDATE は行ロックを取りながら現在値に対して実行されるため、同時実行でも条件が正しく評価されます。SELECT と UPDATE の間の隙間が存在しません。

デッドロックはなぜ起きるか

2つのトランザクションが、互いに相手が持っているロックを待つ状態です。

A: 商品1 をロック → 商品2 のロックを待つ
B: 商品2 をロック → 商品1 のロックを待つ
→ 永遠に解けない

DB はこれを検出して片方を強制終了します。アプリ側はエラーを受け取り、リトライする必要があります。

予防策は ロックを取る順序を揃えること。常に ID の昇順でロックすれば、循環が発生しません。

// ID 順に並べてからロックする
const ids = [productB, productA].sort((a, b) => a - b);
for (const id of ids) {
  await db.query('SELECT * FROM products WHERE id = ? FOR UPDATE', [id]);
}

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。