使用しようとしています
DROP TABLE IF EXISTS <myTableName>;
しかし、数時間経ってもまだ実行されています。回避策の提案はありますか?
ベストアンサー1
より良い方法:
DROP操作の邪魔になるすべてのプロセスを強制終了します
tableデータベース内のテーブルを削除したいとしますdatabase
1) 並列セッションで、できれば root として mysql にログインします。問題:
SHOW PROCESSLIST;
db 上のすべてのプロセスのリストが表示されます* :
+-------+-----------+-----------+----------+---------+------+---------------------------------+------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+-------+-----------+-----------+----------+---------+------+---------------------------------+------------------------------+----------+
| 38239 | username | 10.0.0.1 | database | Sleep | 591 | | NULL | 0.000 |
| 38240 | username | 10.0.0.1 | database | Sleep | 590 | | NULL | 0.000 |
| 38245 | username | 10.0.0.1 | database | Query | 2636 | Waiting for table metadata lock | DROP TABLE IF EXISTS `table` | 0.000 |
| 38257 | username | localhost | database | Query | 0 | init | SHOW PROCESSLIST | 0.000 |
+-------+-----------+-----------+----------+---------+------+-------+---------------------------------+----------------------+----------+
2) アクティブなプロセスがある場合前にDROP の場合は、完了するまで待つ必要があります (確実であれば、終了させることもできます)。
3) 次に、待機中のプロセスの前に「スリープ」しているすべてのプロセスを終了します。
KILL 38239;
KILL 38240;
4) その後、ブロックされたプロセスは DROP 操作を続行する必要があります。
DROP の前に待機することは、InnoDB の既知の問題です。
アップデート：また、次のような非排他的更新 (影響を受けるレコードの数が変化する可能性がある更新) でもこの動作が確認されました。
# may update any number of customers, from 0 to all
UPDATE customers SET `active` = 'N' WHERE `last-payment-date` < 2018-01-01;
解決策はまったく同じです。
- 提供されている表は実際のシナリオから取得されており、セキュリティとプレゼンテーションの目的でデータは難読化され、若干編集されています。