Deadlock found（デッドロック）

一言でいうと（このエラーが何を意味するか）

Deadlock found when trying to get lock; try restarting transaction（MySQL/InnoDB のエラー番号 1213、SQLSTATE 40001）は、2つ以上のトランザクションが互いに相手の保持するロックを待ち、永遠に進めなくなったことを DB が検知し、そのうち1つを強制的に巻き戻して膠着を破ったという通知です。

デッドロックは「循環待機（circular wait）」です。トランザクション T1 がロック A を持ったまま B を要求し、同時に T2 が B を持ったまま A を要求すると、両者は相手の解放を待ち続けます。InnoDB は各ロック待ちを有向辺とする待ちグラフ（wait-for graph）を持ち、辺を張った瞬間に閉路を探索します。閉路が見つかれば、そのトランザクションの1つを犠牲者（victim）に選んでロールバックし、他方を進行させます。

横にスクロール

よくある原因（複数を具体的に、頻度順）

1. 複数行を触る順序の不一致（最頻）。2つのトランザクションが同じ2行 A, B を更新するとき、片方が A→B、もう片方が B→A の順にロックを取ると循環が生じます。送金処理で「口座番号の小さい方から引く」といった規約がないコードで典型的に起こります。ロックは行ごとに、その行を更新（または SELECT ... FOR UPDATE）した順に取得されるため、経路が交差した瞬間にデッドロックの窓が開きます。

2. ギャップロックによる想定外の競合。InnoDB の既定分離レベル REPEATABLE READ では、範囲更新やユニークでないインデックス経由の更新が、実在する行だけでなく行と行の間の隙間（ギャップ）にもロックをかけます。異なる値を挿入する2つの INSERT が同じギャップロックを共有取得した後、互いに挿入意図ロック（insert intention lock）へ昇格しようとして詰まる、という競合が起こります。「別々の行なのに衝突する」場合はこれを疑います。

3. 長いトランザクション。ロックを長時間保持するほど、他とロック範囲が重なる確率が上がります。トランザクション内でのアプリ側の待機（外部API呼び出し、ユーザー入力待ち）、巨大な範囲更新、コミット忘れが典型です。保持時間が延びると 1205 も 1213 も両方増えます。

4. インデックス不足による広すぎるロック。更新の WHERE に使えるインデックスがないと、InnoDB は行を絞り込めず走査した多数の行にロックをかけ、本来無関係な行同士が競合してデッドロック確率が跳ね上がります。

診断の手順（切り分け方・見るべきログ/コマンド）

まず直近のデッドロックを見る。InnoDB は最後に検知したデッドロックの詳細を保持しています。

SHOW ENGINE INNODB STATUS;

出力の LATEST DETECTED DEADLOCK セクションに、関与した2つのトランザクション（TRANSACTION 1, TRANSACTION 2）それぞれの実行中 SQL、保持ロック（HOLDS THE LOCK(S)）、待機ロック（WAITING FOR THIS LOCK）、そして WE ROLL BACK TRANSACTION (n)（どちらを犠牲にしたか）が記録されます。保持ロックと待機ロックのインデックス名・ロック種別（X, S, gap, insert intention）を突き合わせれば、どの行・ギャップで循環したかが特定できます。

SET GLOBAL innodb_print_all_deadlocks = ON;

発生時点の全ロック状況を見る。現在どのトランザクションがどのロックを保持・待機しているかは、performance_schema から確認できます（MySQL 8.0 以降）。

SELECT * FROM performance_schema.data_lock_waits;
SELECT * FROM performance_schema.data_locks;

data_lock_waits は「待っている側（requesting）」と「待たせている側（blocking）」の内部トランザクション ID を対にして返すため、待ちグラフの辺を直接読めます。さらに information_schema.innodb_trx で問題トランザクションの経過時間や実行 SQL を掘り下げます。

SELECT trx_id, trx_state, trx_started, trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

再現とロック粒度の確認。疑わしい更新文の前に EXPLAIN をかけ、想定したインデックスが使われているか（type が range/ref か、ALL の全走査でないか）を確認します。全走査ならロックが広がりデッドロックの温床になります。

解決と予防（対処と再発防止）

行の取得順序を統一する（最重要）。複数行を更新するトランザクションは、常に同じ順序（主キーの昇順など、全アプリで一貫した規約）でロックを取ります。これにより待ちグラフに閉路が生じ得なくなり、原因1のデッドロックは原理的に消えます。

-- 悪い例: 呼び出し側次第で 100→200 と 200→100 が混在し循環し得る
UPDATE accounts SET balance = balance - 50 WHERE id = :from;
UPDATE accounts SET balance = balance + 50 WHERE id = :to;

-- 良い例: id の小さい行から必ずロックし、順序を固定する
SELECT id FROM accounts
WHERE id IN (:from, :to)
ORDER BY id
FOR UPDATE;
-- 以降で残高を更新する

必ずリトライを実装する。順序を統一しても、ギャップロックや実行計画の変化で残るデッドロックはゼロにできません。1213 を受けたらそのトランザクション全体を巻き戻して、短いランダム遅延（指数バックオフ）を挟み再実行します。エラーが「try restarting transaction」と促すのはこのためで、犠牲者側は既にロールバック済みなので安全に最初からやり直せます。

import time, random

for attempt in range(3):
    try:
        run_transaction()      # BEGIN 〜 COMMIT を丸ごと
        break
    except DeadlockError:      # MySQL 1213 / SQLSTATE 40001
        if attempt == 2:
            raise
        time.sleep(random.uniform(0.05, 0.2) * (attempt + 1))

トランザクションを短く保つ。ロック取得はできるだけコミット直前に寄せ、トランザクション内に外部 API 呼び出しやユーザー入力待ちを入れない。処理と DB ロックの保持時間を切り離すほど競合窓が縮みます。

ロック粒度を狭める。更新の WHERE に効くインデックスを用意して走査行数を最小化し、余計な行・ギャップをロックしない。ギャップロックが問題で非反復読み取りを許容できるなら、分離レベルを READ COMMITTED に下げるとギャップロックが原則消えてデッドロックが減る場合があります（許容可否を必ず評価してから）。

デッドロックの土台にあるロックとトランザクション分離の原理はデータベースを、循環待機を含む一般の並行制御と資源割り当ての理論はOSを、リトライやバックオフを堅牢に組む実装作法はプログラミングを参照してください。