MySQLの修復を停止する必要がありますか？
MySQLデータベース（20ギガバイトのテーブルとインデックス）が破損しました。 MySQL-adminグラフィックインターフェイスを使用して修復オプションを起動しましたが、24時間実行されています。 MyISAMオプション（バッファー、スレッドなど）を確認したところ、パフォーマンスが非常に低いことに気付きました。1つの修復スレッド、8 Mbのソートバッファー...
私の質問は、修復プロセスを停止して、より適切な構成で再起動するか、実行を継続して待機するかです。修復プロセスが何をしているのか、またはどれくらいかかるのかを知る方法はありますか？
データディレクトリの内容を監視することで、修復の進行状況を追跡できます。修復中に使用される＃で始まる名前のテーブルが表示されます。
SHOW PROCESSLISTをチェックして、「Repair with keycache」よりもはるかに悪いため、「Repair with keycache」を実行していないことを確認することもできます
大きなテーブルでは修復が非常に遅くなります。 MyISAMでは、特にインデックスが多い非常に大きなテーブルは避ける必要があります。修復時間を短縮するために、代わりにそれらを分割することをお勧めします。これには、アプリケーションコードの大幅な変更が必要になる場合があります。
プロセスを停止しないことを強くお勧めします。
プロセスリストに表示される1つのスレッドはMySQLの動作方法であり、途中で停止すると既存のデータベースに損傷を与える可能性があります。
データベースが破損して何が起こったのかについて、もっと詳しい情報を提供できるでしょうか？
10のスターターとして、「show processlist;」を実行して、修復がアクティブに実行されていることを確認できます。 MySQLプロンプトから。
（おそらくあなたが探していた答えではありませんが、うまくいけば、それは道に沿った一歩です。）
[ああ-MarkRに殴られた。]
ディスクが一時ファイルでいっぱいになったため、私の修復には永遠に時間がかかりました。気づかなかった。 mysqlディレクトリのservername.errファイルには、次のような行が含まれていました。
101104 5:43:24 [エラー]/usr/sbin/mysqld：ディスクは「/ tmp/STiktcbP」を書き込み中です（エラーコード：28）。誰かが空き容量を増やすのを待っています... 60秒後に再試行してください
php.iniの時間制限を確認してください。300秒後にスクリプトが停止した可能性があります。 （phpinfo（）を実行して出力を確認することもできます）
コマンドラインのmysqlインターフェイスを介してのみ、このような大きなDBの修復を行う必要があります。