DROP DATABASEがなぜこんなに時間がかかるのですか？ （MySQL）
新しいCentOSインストール。
大きなDB（2GB sqlファイル）のインポートを実行していて、問題がありました。 SSHクライアントは接続を失い、インポートがフリーズしたようです。別のウィンドウを使用してmysqlにログインしたところ、インポートが停止しているように見え、特定の3M行テーブルでスタックしました。
だから私は試しました
DROP DATABASE huge_db;
15-20分後、何もありません。別のウィンドウで、私はしました：
/etc/init.d/mysqld restart
メッセージDROP DBウィンドウ：SERVER SHUTDOWN。その後、実際に物理サーバーを再起動しました。
Mysqlに再度ログインし、チェックしましたが、dbはまだそこにあり、実行されました
DROP DATABASE huge_db;
再び、そして私はすでに約5分待っています。
もう一度、それは新鮮なインストールです。 huge_dbが唯一のデータベースです（システムデータベース以外）。私は以前にこれほど大きなdbをドロップしたことを誓いますが、おそらく私は間違っています。
データベースを正常に削除しました。 30分くらいかかりました。また、mysqldumpインポートが無効であると思ったとき、私は間違っていたと思います。端末接続は失われましたが、プロセスはまだ実行されていたと思います。最も可能性が高いのは、インポートの中間テーブル（3Mの行テーブル）と、おそらくデータベース全体の3/4を強制終了したことです。 "top"がmysqlにメモリの3％しか使用していないことを示していたのは誤解を招きました。
DBの削除に30分かかったため、サーバーを再起動する必要がなく、DROPが完了するのを待っていた可能性がありますが、DROPクエリの取得に対するmysqlの反応はわかりません。 mysqldumpを介してインポートしているのと同じデータベース。
それでも問題は残ります。2GBのデータベースを削除するのに、すべてのdbファイルを削除し、information_schemaからDBへのすべての参照を削除するだけで、30分以上かかるのはなぜですか。大したことは何ですか？
プロセスを強制終了するのではなく、MySQL内で実行した方が安全です。
$ mysqladmin processlist -u root -p
Enter password:
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example | Sleep | 297 | | |
| 407 | root | localhost | | Query | 0 | | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
Id 174のクエリは、「example」データベースの削除をブロックするものです。そのため、プロセスを終了する前に、MySQLにクエリを終了させてください。
$ mysqladmin kill 174
上記のprocesslistコマンドを再度実行して、強制終了されたことを確認します。
これが機能しない場合は、誤ったプロセスを強制終了することを検討できますが、その前にMySQLサーバーを再起動してみてください。
MySQLクライアントのみがインストールされている場合など、MySQLシェルで「SHOW FULL PROCESSLIST」や「KILL 174」などのコマンドを実行することもできます。重要な点は、どうしても必要な場合を除き、シェルで「kill」を使用してプロセスを強制終了しないようにすることです。
一般的に言えば、mysqlまたはmysqladminを使用できます。ただし、このようなコマンドを頻繁に実行する必要はありません。クエリを定期的にkillし始めると、何かが間違いなく間違っているので、その問題を修正したほうがよいでしょう（queryプロセスをkillすることは単に症状を処理することです）。
インポートプロセスが停止したと思いましたが、おそらくまだ実行中です。
DROP DATABASEコマンドは、データベースが実行される前に、データベースのインポートが完了するのを待っている可能性があります。
したがって、DROP DATABASEに長い時間をかけるのではなく、おそらくインポートだけでした。
他の誰かがこれを読んで、データベースのインポートをキャンセルしてデータベースを削除しようとしている場合は、最初にインポートのPID（プロセスID）を見つけて、別のターミナルから実行することをお勧めします。
$ kill [PID]
... [PID]はプロセスの実際のPIDです。
他の端末がまだ接続されている場合は、インポートがすぐに停止するはずです。
PhpMyAdminのSQLタブでSHOW PROCESSLISTを実行することもできます。結果のテーブルには実行中のプロセスが表示され、強制終了する行の横にある「x」をクリックするとうまくいきます。
次に実行します
DROP DATABASE `database_name`;
そして、すべてがきれいでなければなりません。
別の答えは、mysql内でプロセスを強制終了することは、外部から実行するよりも良いことを示唆しています。私はその答えをテストしていませんが、それは非常にもっともらしいようです。そのため、これではなく「受け入れられた回答」としてマークしました。
データベースを削除する前に、データベース内の最大のテーブルを切り捨ててください。ファイアウォールトラフィックのMySQLアーカイブを操作するときに非常によく似た動作が見られましたが、これは非常に役立ちました。
私は同じ問題に直面しました。しかし、今回はshow processlistを確認しました。それはより長い時間許可をチェックすることを言った。次に、mysqld_safeがrootとして実行されていたのに、フォルダレベルのアクセス許可はmysqlユーザーのみにあることがわかりました。したがって、私はクエリを強制終了しました。もちろん、それが強制終了状態であると言うのに長い時間がかかりましたが、それが反応するのを待ってからクエリを強制終了し、グループおよびchmodに追加して、フォルダレベルのアクセス許可をrootに変更しました。その後、770に実行しました。同じドロップデータベースが何とか。 20GBデータベースの場合、2秒でうまくいきました。
最初に頭に浮かぶのは、ステータスChecking Permissions...です。
DROP DATABASE mydb;を発行すると、/ var/lib/mysql/mydb内のすべてがチェックされ、すべてのファイルをドロップする権限に対するOS権限が存在するかどうかが確認されます。