MySQL 死鎖排查實戰：通過 information_schema.INNODB_TRX 秒級定位持鎖線程

現場復現

• 線程 A（ID=16）：BEGIN; UPDATE t3 SET ... WHERE id=19; **未提交**，處於 Sleep 狀態持有行鎖。
• 線程 B（ID=17）：UPDATE t3 SET ... WHERE id=19; 等待鎖超時，報 ERROR 1205 (HY000): Lock wait timeout exceeded。
• SHOW PROCESSLIST 只見 Sleep，**無法直接看出誰持有鎖**。

標準排查步驟

1. SHOW ENGINE INNODB STATUS\G → 手動分析 TRANSACTIONS 區塊，**信息冗長、難自動化**。
2. **推薦：直接查系統表** information_schema.INNODB_TRX。

一鍵定位 SQL

SELECT * FROM information_schema.INNODB_TRX\G

關鍵輸出字段：

實戰輸出解讀

*************************** 1. row ***************************
trx_id: 189324
trx_state: RUNNING
trx_started: 2013-04-18 17:48:14
trx_mysql_thread_id: 16   -- 就是這個線程！
trx_query: NULL           -- 空查詢，說明在事務中間空閒
trx_tables_locked: 1
trx_rows_locked: 3
trx_rows_modified: 1
trx_isolation_level: REPEATABLE READ

結論：線程 16 開啟事務後修改數據，**忘記 COMMIT/ROLLBACK**，長時間持有鎖導致阻塞。

解決動作

KILL 16;  -- 直接殺掉持鎖線程，事務自動回滾，釋放鎖

線程 B 即可繼續執行。

輔助視圖：INNODB_LOCKS / INNODB_LOCK_WAITS（5.7+）