回答:
SHOW ENGINE INNODB STATUS \G
セクションを探す-
TRANSACTIONS
INFORMATION_SCHEMAテーブルを使用できます。
便利なクエリ
トランザクションが待機しているすべてのロックについて確認するには:
USE INFORMATION_SCHEMA;
SELECT * FROM INNODB_LOCK_WAITS;
ブロッキングトランザクションのリスト:
SELECT *
FROM INNODB_LOCKS
WHERE LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM INNODB_LOCK_WAITS);
または
SELECT INNODB_LOCKS.*
FROM INNODB_LOCKS
JOIN INNODB_LOCK_WAITS
ON (INNODB_LOCKS.LOCK_TRX_ID = INNODB_LOCK_WAITS.BLOCKING_TRX_ID);
特定のテーブルのロックのリスト:
SELECT * FROM INNODB_LOCKS
WHERE LOCK_TABLE = db_name.table_name;
ロックを待っているトランザクションのリスト:
SELECT TRX_ID, TRX_REQUESTED_LOCK_ID, TRX_MYSQL_THREAD_ID, TRX_QUERY
FROM INNODB_TRX
WHERE TRX_STATE = 'LOCK WAIT';
リファレンス - MySQLのトラブルシューティング:何するために行うクエリが機能しない、第6章-ページ96。
テーブルをロックしているプロセスが見つからない場合(それはすでに死んでいるため)、それはまだこのようにクリーンアップしているスレッドである可能性があります
セクションTRANSACTION of
show engine innodb status;
最後に
---TRANSACTION 1135701157, ACTIVE 6768 sec
MySQL thread id 5208136, OS thread handle 0x7f2982e91700, query id 882213399 xxxIPxxx 82.235.36.49 my_user cleaning up
トランザクションのデッドロックをクリアするのコメントで述べたように ?
ここでは、トランザクションスレッドを強制終了することができます。
KILL 5208136;
私のために働いた。
Datagripにも同様の問題があり、これらのソリューションはどれも機能しませんでした。
Datagripクライアントを再起動すると、問題はなくなり、テーブルを再度ドロップできました。
INFORMATION_SCHEMA
データベースにあることに注意してください。