InnoDBで行ロックとMVCCはどのように機能し、デッドロックをどう回避しますか。

Question

IT Interview Practice · Accepted Answer

InnoDBは2つの仕組みを組み合わせます。**MVCC**により、通常の`SELECT`はロックせずに一貫したスナップショットを読めるため、読み手が書き手をブロックすることはありません。**ロック**は書き込みを保護します。`UPDATE`/`DELETE`/`SELECT ... FOR UPDATE`は行ロックを取得し、InnoDBはさらに**next-key lock**（行＋その前のギャップ）を用いて、REPEATABLE READ下でphantomを防ぎます。

## デッドロック

デッドロックは循環です。T1はロックAを保持してBを求め、T2はBを保持してAを求めます。どちらも先へ進めません。InnoDBは**循環を検出し、一方のトランザクションをロールバック**します（コストの低い方を犠牲にする）。error 1213を返し、もう一方が完了します。

```sql
-- T1                              -- T2
BEGIN;                             BEGIN;
UPDATE acct SET bal=bal-1          UPDATE acct SET bal=bal-1
  WHERE id=1;  -- locks row 1        WHERE id=2;  -- locks row 2
UPDATE acct SET bal=bal+1          UPDATE acct SET bal=bal+1
  WHERE id=2;  -- waits for T2        WHERE id=1;  -- waits for T1 => DEADLOCK
-- ERROR 1213: Deadlock found; transaction rolled back
```

## 回避する方法

- **一貫したロック順序** — 常に同じ順序で行に触れる（例: idの昇順）。上の例は、2つのトランザクションが1→2と2→1でロックするからこそデッドロックします。
- **トランザクションを短く保つ** — ロックの取得は遅く、コミットは速く、ネットワークやユーザーの待ちをまたいでロックを保持しない。
- **最小限をロックする** — `WHERE`にインデックスを張り、InnoDBが範囲や（インデックスなしで）実質的にスキャンした全行ではなく、特定の行だけをロックするようにする。
- **1213でリトライする** — デッドロックは競合下では正常です。トランザクションをアプリケーションレベルのリトライで包んでください。

```sql
SHOW ENGINE INNODB STATUS\G   -- LATEST DETECTED DEADLOCK explains who waited on what
```

## なぜ重要なのか

実際の並行処理下では、ロック競合とデッドロックが、スケールするデータベースと停滞するデータベースの分かれ目になります。読み手はMVCCを使う（だからブロックしない）こと、デッドロックは想定内でリトライ可能であること、そして一貫したロック順序がその大半を防ぐことを知っていることは、まさにシニアのオンコール業務が求めるものです。

デッドロック

回避する方法

なぜ重要なのか

関連する質問