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に再度ログインしてチェックし、データベースがまだそこにあった、実行した

DROP DATABASE huge_db;

再び、そして再び私はすでに約5分待っています。

繰り返しますが、新規インストールです。huge_db（システムDBS以外の）唯一のDBです。私は以前にこれほど速くdbをドロップしたことを誓いますが、多分間違っています。

データベースを正常に削除しました。30分ほどかかりました。また、mysqldumpのインポートが死んだと思ったとき、私は間違っていたと思うことに注意してください。端末の接続は失われましたが、プロセスはまだ実行中だったと思います。インポート中テーブル（3M行テーブル）を削除した可能性が最も高く、おそらくデータベース全体の3/4を削除しました。「top」がmysqlを使用してメモリを3％しか使用していないことを示していたのに、それ以上使用する必要があるように思えたのは誤解を招きました。

DBの削除には30分かかりました。そのため、サーバーを再起動する必要がなく、DROPが完了するのを待つこともできましたが、DROPクエリの取得に対するmysqlの反応はわかりません。 mysqldump経由でインポートするのと同じdb。

それでも、疑問が残ります。すべてのdbファイルを削除し、information_schemaからDBへのすべての参照を削除するだけで2 GBのデータベースを削除するのに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。ただし、このようなコマンドを頻繁に実行する必要はありません。クエリを定期的に削除し始めたら、何か間違いがあるので、その問題を修正した方がよいでしょう（クエリプロセスを削除することは、単に症状を治療することです）。

インポートプロセスは終了したと思いましたが、おそらくまだ実行中でした。

DROP DATABASEコマンドは、おそらくそれが実行する前に、インポート仕上げにデータベースを待っていました。

したがって、DROP DATABASE長い時間をかけるのではなく、おそらく単なるインポートでした。

他の誰かがこれを読み、データベースのインポートをキャンセルしてデータベースをドロップしようとしている場合、まずインポートのPID（プロセスID）を見つけて別の端末から実行することをお勧めします。

$ kill [PID]

... [PID]はプロセスの実際のPIDです。

他の端末がまだ接続されている場合、インポートがすぐに停止するはずです。

またSHOW PROCESSLIST、phpMyAdmin SQLタブで実行することもできます。結果のテーブルには実行中のプロセスが表示されます。削除したい行の横にある「x」をクリックすると、トリックが実行されます。

次に実行する

DROP DATABASE `database_name`;

そして、すべてがきれいでなければなりません。

別の答えは、mysql内でプロセスを強制終了する方が、外部から実行するよりも優れていることを示唆しています。私はその答えをテストしていませんが、非常にもっともらしいようです。それで、私はこれを「受け入れられた答え」としてマークしました。

データベース内の最大のテーブルを削除する前に切り捨ててみてください。ファイアウォールトラフィックのMySQLアーカイブを操作すると、非常によく似た動作が見られ、これは非常に役立ちました。

最初に頭に浮かぶのはステータスです Checking Permissions...

DROP DATABASE mydb;/ var / lib / mysql / mydb内のすべてを発行すると、すべてのファイルをドロップする権限に対するOS権限が存在するかどうかが確認されます。

一部の人は、mysqlユーザーの数を減らすことが役立つと感じています

私は同じ問題に直面した。しかし、今回はshow processlistをチェックしました。それはより長い時間の許可のチェックを言った。それから、mysqld_safeがrootとして実行されているのに対し、フォルダーレベルの権限はmysqlユーザーのみに許可されていることがわかりました。したがって、クエリを強制終了しました。もちろん、強制終了状態であると言うのに長い時間がかかりましたが、反応するのを待ってからクエリを強制終了し、グループに追加してフォルダレベルのアクセス許可をルートに変更し、chmodを770にしました。同じドロップデータベースブラー; 20GBデータベースの場合、2秒で機能しました。