MySQL Lock wait timeout exceededの原因と直し方

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction は、別のトランザクションがロックしている行を、決められた秒数（既定 50 秒）待っても取れなかったときのエラーです。 原因の多くは「COMMIT されないまま残っているトランザクション」です。

直し方の順番は次のとおりです。

1. 待たせている相手（ブロッカー）を sys.innodb_lock_waits で特定する
2. 相手の接続が何をしているか見て、COMMIT させるか KILL <接続ID> で切る（KILL QUERY では解けないことが多い）
3. 再発を防ぐ：トランザクションを短くする、WHERE の列にインデックス、1205 のリトライ

-- 待っている側・待たせている側を1行で見る（MySQL 8.0）
SELECT waiting_pid, waiting_query, blocking_pid, blocking_query,
       sql_kill_blocking_connection
FROM sys.innodb_lock_waits;

確認環境：MySQL 8.0.46（Ubuntu 24.04 の apt パッケージ）、InnoDB、分離レベルは既定の REPEATABLE READ。Python 3.11 と PyMySQL で2つの接続を作り、この記事のエラー・待ち時間・ロックの表示を再現しました。innodb_rollback_on_timeout は ON にした別の mysqld を起動して比べました。仕様は MySQL 8.0 リファレンスマニュアルで確かめました（確認日 2026年10月13日）。

エラーが出るまでの流れ（再現）

在庫テーブル stock で、2つの接続が同じ行を更新します。

CREATE TABLE stock (id INT PRIMARY KEY, sku VARCHAR(20), qty INT, price INT);
INSERT INTO stock VALUES (1,'A-001',10,100),(2,'A-002',5,200),(3,'A-003',8,300),
                         (10,'B-010',1,1000),(20,'B-020',2,2000);

-- 接続A
BEGIN;
UPDATE stock SET qty = qty - 1 WHERE id = 1;   -- COMMIT しないまま

-- 接続B
SET SESSION innodb_lock_wait_timeout = 5;
BEGIN;
UPDATE stock SET qty = qty - 1 WHERE id = 1;   -- A の COMMIT を待つ

接続B は 5.00 秒 止まったあと、次のエラーになりました。

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

A は何も実行していない（アイドル）のに、ロックを持ち続けています。 InnoDB の行ロックは COMMIT か ROLLBACK まで解放されないためです。アプリで例外が起きて COMMIT も ROLLBACK もされない、コネクションプールに戻した接続でトランザクションが開いたまま、といった形で起きます。

待たせている相手を特定するSQL

MySQL 8.0 では、ロック待ちの情報は performance_schema.data_lock_waits（待ちの組）と performance_schema.data_locks（ロックそのもの）にあります。5.7 までの information_schema.INNODB_LOCK_WAITS・INNODB_LOCKS は 8.0 で削除され、これに置き換わりました。

sys.innodb_lock_waits（一番手軽）

sys スキーマのビューで、待ちの組を1行にまとめて見せてくれます。上の再現中に実行した結果です。

SELECT wait_started, wait_age, locked_table, locked_index, locked_type,
       waiting_pid, waiting_query, waiting_lock_mode,
       blocking_pid, blocking_query, blocking_lock_mode,
       sql_kill_blocking_query, sql_kill_blocking_connection
FROM sys.innodb_lock_waits\G

                wait_started: 2026-10-13 06:48:14
                    wait_age: 0:00:01
                locked_table: `s175shop`.`stock`
                locked_index: PRIMARY
                 locked_type: RECORD
                 waiting_pid: 20
               waiting_query: UPDATE stock SET qty = qty - 1 WHERE id = 1
           waiting_lock_mode: X,REC_NOT_GAP
                blocking_pid: 19
              blocking_query: NULL
          blocking_lock_mode: X,REC_NOT_GAP
     sql_kill_blocking_query: KILL QUERY 19
sql_kill_blocking_connection: KILL 19

blocking_query が NULL なのは、相手がアイドルだからです。 「相手の SQL が分からない」ときは、次の方法で直前に実行した SQL を見られます。

待たせている側が直前に実行したSQLを見る

performance_schema.events_statements_history には、接続ごとに直近の SQL が残っています（既定で1スレッド10件）。

SELECT w.blocking_pid, t.trx_started, t.trx_rows_locked, t.trx_rows_modified, h.sql_text
FROM sys.innodb_lock_waits w
JOIN information_schema.innodb_trx t ON t.trx_mysql_thread_id = w.blocking_pid
JOIN performance_schema.threads th ON th.processlist_id = w.blocking_pid
JOIN performance_schema.events_statements_history h ON h.thread_id = th.thread_id
ORDER BY h.event_id;

再現中の結果です。A が UPDATE ... WHERE id = 1 を実行したあと、別の SELECT を実行してアイドルになっている様子が分かりました。

同じ時点の SHOW PROCESSLIST では、A は Command: Sleep・Info: NULL、B は Command: Query・State: updating でした。PROCESSLIST だけでは、どの Sleep の接続が原因かは分かりません。 sys.innodb_lock_waits で blocking_pid を確かめます。

performance_schema を直接 JOIN する書き方

sys スキーマを使えない権限のときは、元のテーブルを JOIN します。

SELECT r.trx_mysql_thread_id AS waiting_thread,
       r.trx_query           AS waiting_query,
       b.trx_mysql_thread_id AS blocking_thread,
       b.trx_query           AS blocking_query,
       b.trx_started         AS blocking_started
FROM performance_schema.data_lock_waits w
JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_engine_transaction_id
JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_engine_transaction_id;

ロックの一覧そのものは data_locks で見られます。

SELECT object_name, index_name, lock_type, lock_mode, lock_status, lock_data
FROM performance_schema.data_locks;

+-------------+------------+-----------+---------------+-------------+-----------+
| object_name | index_name | lock_type | lock_mode     | lock_status | lock_data |
+-------------+------------+-----------+---------------+-------------+-----------+
| stock       | NULL       | TABLE     | IX            | GRANTED     | NULL      |  ← A
| stock       | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 1         |  ← A が id=1 を持つ
| stock       | NULL       | TABLE     | IX            | GRANTED     | NULL      |  ← B
| stock       | PRIMARY    | RECORD    | X,REC_NOT_GAP | WAITING     | 1         |  ← B が id=1 を待つ
+-------------+------------+-----------+---------------+-------------+-----------+

必要な権限：sys.innodb_lock_waits を読むには、sys スキーマの SELECT・EXECUTE、performance_schema の SELECT、information_schema.innodb_trx を見るための PROCESS 権限を付けたユーザーで実行しました。

KILL QUERY では解けない：KILL で接続を切る

sys.innodb_lock_waits には sql_kill_blocking_query（KILL QUERY 19）と sql_kill_blocking_connection（KILL 19）の2つが出ます。相手がアイドルのときは KILL QUERY では解けませんでした。

KILL QUERY は「実行中の SQL を止める」もので、トランザクションは残ります。KILL <接続ID> は接続を切り、COMMIT していない変更はロールバックされます。 本番で切るときは、trx_rows_modified（変更した行数）と直前の SQL を見て、ロールバックされてよいかを確かめてから実行します。接続の見方は、関連記事「MySQL SHOW PROCESSLISTの見方とKILLでの切断」で扱っています。

原因別の再現：同じ行でなくても待つ

ギャップロック：範囲の FOR UPDATE と INSERT

REPEATABLE READ（MySQL の既定）では、範囲を検索してロックすると、行と行の間（ギャップ）もロックされます。 ほかのトランザクションが、その間に INSERT できなくなります。

-- 接続A：id 3〜15 をロック（実在する行は 3 と 10）
BEGIN;
SELECT * FROM stock WHERE id BETWEEN 3 AND 15 FOR UPDATE;

-- 接続B：存在しない id=5 の INSERT
INSERT INTO stock VALUES (5,'A-005',1,500);   -- 待つ → ERROR 1205

A が持っていたロックは次の3つでした（data_locks）。

B は X,GAP,INSERT_INTENTION（挿入意図ロック）で lock_data: 10 を待っていました。id=5 は 3 と 10 の間なので、A のネクストキーロックとぶつかったということです。

存在しない行への FOR UPDATE でも起きます。 SELECT * FROM stock WHERE id = 15 FOR UPDATE（id=15 は無い）のあと、別の接続で id=12 を INSERT すると待ちました。A は X,GAP・lock_data: 20、つまり 10〜20 の間をロックしていました。「無ければ INSERT」を FOR UPDATE で書くと、この形で待ち合いになります。UPSERT の書き方は、関連記事「SQL UPSERTの書き方｜PostgreSQL・MySQL・MERGE構文比較表」で扱っています。

同じ操作を READ COMMITTED で行うと、B の INSERT はすぐ成功しました（0.00 秒）。 MySQL のマニュアルには「READ COMMITTED では、検索とインデックススキャンのギャップロックは無効になり、外部キーのチェックと重複キーのチェックにだけ使われる」とあります。分離レベルを変えると、ファントム（同じ範囲を読み直すと行が増える）が起きうるので、影響を確かめてから変えます。分離レベルの違いは、関連記事「トランザクション分離レベルの違いをわかりやすく解説」で扱っています。

WHERE の列にインデックスが無い

sku にインデックスが無い状態で、A と B が別の行を更新しました。

-- 接続A
BEGIN;
UPDATE stock SET qty = 0 WHERE sku = 'A-001';   -- id=1 の行

-- 接続B
UPDATE stock SET qty = 0 WHERE sku = 'B-020';   -- id=20 の行。それでも待つ → ERROR 1205

A の data_locks には、id=1・2・3・10・20 の全行と supremum pseudo-record（最後の行の後ろ）に X ロックが並んでいました。 インデックスが無いと、InnoDB は主キーで全行を読みながらロックするためです。B は lock_data: 1 で待っていました。

READ COMMITTED では、条件に合わなかった行のロックを外すため、別の行なら待ちませんでした。根本の直し方は、WHERE の列にインデックスを付けることです（ALTER TABLE stock ADD INDEX idx_sku (sku);）。UPDATE や DELETE が EXPLAIN で type: ALL になっていないかを確かめます。見方は関連記事「MySQL EXPLAINの見方｜type・key・rows・Extra早見表」で扱っています。

外部キー：親の行が更新中

orders.stock_id が stock.id を参照する外部キーで、A が stock の id=1 を更新したまま、B が INSERT INTO orders (stock_id) VALUES (1) を実行すると、3.01 秒待って ERROR 1205 になりました。子テーブルへの INSERT は、外部キーのチェックで親の行に共有ロックを取りに行くためです。

ALTER TABLE も同じ 1205 になる（メタデータロック）

ALTER TABLE が、開いたままのトランザクションを待っても 1205 が出ます。 ただし、これは行ロックではなくメタデータロック（テーブルの定義を守るロック）で、待つ秒数を決めるのは lock_wait_timeout です。

-- 接続A
BEGIN;
SELECT * FROM stock WHERE id = 1;   -- 読んだだけでもテーブルのメタデータロックを持つ

-- 接続B
SET SESSION lock_wait_timeout = 3;
ALTER TABLE stock ADD COLUMN note VARCHAR(10);   -- 3.00 秒後に ERROR 1205

このとき、PROCESSLIST の State は Waiting for table metadata lock で、sys.innodb_lock_waits は0行でした。 メタデータロックの待ちは sys.schema_table_lock_waits に出ます。

SELECT object_name, waiting_pid, waiting_query, blocking_pid, blocking_lock_type,
       sql_kill_blocking_connection
FROM sys.schema_table_lock_waits;

結果は waiting_query: ALTER TABLE stock ADD COLUMN note VARCHAR(10)、blocking_pid: 74、blocking_lock_type: SHARED_READ、sql_kill_blocking_connection: KILL 74 でした。lock_wait_timeout の既定は 31536000 秒（1年）なので、既定のままだと ALTER はほぼ待ち続け、後ろの SELECT まで詰まります。 ALTER の前に SET SESSION lock_wait_timeout = 数秒; を付けておくと、待ちが長引きません。ALTER の書き方は関連記事「ALTER TABLEでカラム追加・型変更｜MySQL・PostgreSQL比較」で扱っています。

1205 のあと、何がロールバックされるか

既定（innodb_rollback_on_timeout=OFF）では、ロールバックされるのは「タイムアウトした文だけ」で、トランザクションは開いたまま残ります。 同じトランザクションの前の文は残っていて、COMMIT すると反映されました。

-- 接続B（A が id=1 をロック中）
BEGIN;
UPDATE stock SET qty = 99 WHERE id = 2;        -- 成功
UPDATE stock SET qty = qty - 1 WHERE id = 1;   -- ERROR 1205
COMMIT;

OFF のまま「エラーを無視して COMMIT」すると、途中までの変更だけが確定します。 1205 を受けたら、アプリ側で必ず ROLLBACK してから、トランザクションを最初からやり直します。innodb_rollback_on_timeout は起動時にだけ設定できる変数で、SET GLOBAL では ERROR 1238 (HY000): Variable 'innodb_rollback_on_timeout' is a read only variable になりました（my.cnf の [mysqld] に書いて再起動）。

innodb_lock_wait_timeout の確認と変更

SELECT @@global.innodb_lock_wait_timeout, @@session.innodb_lock_wait_timeout;

-- この接続だけ変える（バッチは長め、画面からの更新は短めなど）
SET SESSION innodb_lock_wait_timeout = 10;

-- 全体の既定を変える（このあと接続した分から有効。再起動で戻る）
SET GLOBAL innodb_lock_wait_timeout = 30;

-- 再起動後も残す
SET PERSIST innodb_lock_wait_timeout = 30;

秒数を長くしても、相手が COMMIT しない限り解決しません。 長くするとアプリのスレッドや接続が詰まる時間が延びます。短くして早く失敗させ、リトライする設計のほうが、詰まりが広がりにくくなります。変数の変え方は関連記事「MySQL SHOW VARIABLESとSET PERSIST・my.cnf」で扱っています。

デッドロック（1213）との違い

デッドロックの再現では、A が id=1、B が id=2 を更新したあと、A が id=2、B が id=1 を更新しました。B がすぐ ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction になり、B のそれまでの UPDATE も取り消されていました。 A は待ちが解けて成功しました。

再現を終えたときのカウンタです。

SELECT name, count FROM information_schema.innodb_metrics
WHERE name IN ('lock_deadlocks', 'lock_timeouts');
-- lock_deadlocks 1 / lock_timeouts 9

SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';
-- Innodb_row_lock_current_waits 0（いま待っている数）
-- Innodb_row_lock_waits 12（待った回数の累計）
-- Innodb_row_lock_time_max 5000（最長の待ち、ミリ秒）

監視では Innodb_row_lock_current_waits が増え続けていないか、lock_timeouts が急に増えていないかを見ます。デッドロックの原因と対処は、関連記事「MySQL Deadlock foundの原因と対処｜1213・1205」で扱っています。

待たずに失敗させる：NOWAIT と SKIP LOCKED

MySQL 8.0 では、FOR UPDATE に NOWAIT・SKIP LOCKED を付けられます。A が id=1 をロックしている状態で試しました。

画面の操作で「ほかの人が編集中です」とすぐ返したいときは NOWAIT、ジョブのキューを複数のワーカーで取り合うときは SKIP LOCKED が向いています。ロックの考え方は、関連記事「楽観ロックと悲観ロックの違い｜PostgreSQL実測でわかる使い分け」で扱っています。

アプリ側：1205・1213 をリトライするコード（Python）

1205 を受けたら、まず ROLLBACK してから、トランザクションを最初からやり直します。 文だけを再実行すると、前の文の結果と合わなくなることがあります。

import time
import pymysql

def conn():
    return pymysql.connect(host="127.0.0.1", user="app", password="***", database="shop")

def run_with_retry(work, retries=3, wait=0.5):
    """1205（ロック待ちタイムアウト）と1213（デッドロック）だけ、トランザクションごとやり直す"""
    for attempt in range(1, retries + 1):
        c = conn()
        try:
            with c.cursor() as cur:
                cur.execute("SET SESSION innodb_lock_wait_timeout = 2")
                work(cur)
            c.commit()
            return attempt
        except pymysql.err.OperationalError as e:
            c.rollback()                      # 1205 のあとも必ずロールバックする
            if e.args[0] not in (1205, 1213) or attempt == retries:
                raise
            time.sleep(wait * attempt)        # 少しずつ間隔を空ける
        finally:
            c.close()

def reserve(cur):
    cur.execute("UPDATE stock SET qty = qty - 1 WHERE id = 1 AND qty > 0")

run_with_retry(reserve)

別の接続が id=1 を3秒ロックしたあと COMMIT する状態で動かすと、1回目が 1205 で失敗し、2回目で成功しました（全体で 3.01 秒）。

再発を防ぐチェックリスト

よくある質問

Q. innodb_lock_wait_timeout を大きくすれば直りますか。 A. エラーが出るまでの時間が延びるだけで、待たせている相手が COMMIT しない限り待ちは解けません。バッチ処理など、待つのが前提の処理だけ SET SESSION で長くする使い方が一般的です。

Q. SELECT だけでも 1205 になりますか。 A. ふつうの SELECT はロックを取らない読み取り（一貫性読み取り）なので、行ロックを待ちません。FOR UPDATE・FOR SHARE を付けた SELECT は待ちます。また、ふつうの SELECT でもトランザクション中はメタデータロックを持つので、ALTER TABLE を待たせる側にはなります。

Q. 5.7 では data_lock_waits がありません。 A. 5.7 では information_schema.INNODB_LOCK_WAITS と INNODB_TRX を JOIN します（列名は requesting_trx_id・blocking_trx_id）。これらのテーブルは 8.0 で削除され、performance_schema.data_lock_waits に置き換わりました。sys.innodb_lock_waits は 5.7 の sys スキーマにもあります。

まとめ

• 1205 は、行ロックを innodb_lock_wait_timeout（既定 50 秒）待っても取れなかったエラー
• 相手は sys.innodb_lock_waits で特定。blocking_query が NULL ならアイドルのトランザクション
• アイドルの相手は KILL QUERY では解けず、KILL <接続ID> で切るとロールバックされて解けた
• 同じ行でなくても待つ：範囲の FOR UPDATE（ギャップロック）、インデックスの無い WHERE、外部キー
• 既定では、タイムアウトした文だけが取り消される。1205 のあとは ROLLBACK してやり直す
• ALTER TABLE の 1205 はメタデータロックで、lock_wait_timeout（既定 1年） と sys.schema_table_lock_waits で見る

参考・出典

確認日はいずれも 2026年10月13日です。

• MySQL 8.0 Reference Manual「InnoDB Startup Options and System Variables」（innodb_lock_wait_timeout・innodb_rollback_on_timeout）：https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html
• MySQL 8.0 Reference Manual「InnoDB Locking」（ギャップロック・ネクストキーロック・挿入意図ロック）：https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html
• MySQL 8.0 Reference Manual「The data_lock_waits Table」：https://dev.mysql.com/doc/refman/8.0/en/performance-schema-data-lock-waits-table.html
• MySQL 8.0 Reference Manual「The innodb_lock_waits and x$innodb_lock_waits Views」：https://dev.mysql.com/doc/refman/8.0/en/sys-innodb-lock-waits.html
• MySQL 8.0 Reference Manual「Locking Read Concurrency with NOWAIT and SKIP LOCKED」：https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html
• MySQL 8.0 Reference Manual「Server System Variables」（lock_wait_timeout）：https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。