mysqld を --skip-external-locking で実行している場合（Linux などのシステムではデフォルト）、mysqld が使用している同じテーブルを myisamchk でチェックしても信頼できません。myisamchk の実行中、mysqld からテーブルにアクセスするユーザが確実にない場合のみ、mysqladmin flush-tables を実行してからテーブルをチェックします。テーブルにアクセスするユーザがいるかどうか確信できない場合には、テーブルをチェックする間、mysqld を停止する必要があります。mysqld がテーブルを更新しているときに myisamchk を実行すると、テーブルが破損していない場合でも破損の警告が出る可能性があります。

--skip-external-locking を使用していなければ、いつでも myisamchk を使用してテーブルをチェックできます。この間、テーブルを更新しようとするクライアントはすべて、myisamchk の準備が整うのを待ってから実行します。

myisamchk を使用してテーブルを修復または最適化する場合、必ず、mysqld サーバがそのテーブルを使用していないことを確認してください（--skip-external-locking を使用している場合も同様です）。 mysqld を停止しない場合は、少なくとも mysqladmin flush-tables を myisamchk の前に実行してください。 サーバと myisamchk が同時にテーブルにアクセスすると、テーブルが破損するおそれがあります。

この章では、MySQL データベースのデータ破損のチェック方法およびその対処方法について説明します。テーブルが頻繁に破損する場合は、原因を突き止める必要があります。 See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。

MyISAM テーブルのセクションで、テーブルが破損する原因を示しています。 See 項7.1.3. 「MyISAM テーブルの問題」。

クラッシュをリカバリする際には、データベース内のテーブル tbl_name のそれぞれがデータベースディレクトリ内の次の 3 つのファイルに対応していることを理解しておく必要があります。

これら 3 つのファイルタイプはいずれもさまざまな形で破損する可能性がありますが、特にデータファイルとインデックスファイルに問題がよく発生します。

myisamchk は、.MYD（データ）ファイルのコピーをレコードごとに生成します。修復の最終段階で古い .MYD ファイルを削除し、新規ファイルをオリジナルの名前に変更します。--quick を使用している場合、myisamchk はテンポラリ .MYD ファイルを生成しませんが、代わりに .MYD ファイルが正常であるとみなし、.MYD ファイルに手を加えずに新規インデックスファイルだけを生成します。.MYD ファイルに問題があった場合は myisamchk が自動的に検知して修復を中止するため、この方法も安全です。2 つの --quick オプションを myisamchk に設定することもできます。この場合、myisamchk はいくつかのエラー（重複キーなど）でも中止せず、.MYD ファイルを修正して解決しようとします。通常の修復処理にディスクの空き容量では足りない場合にのみ、2 つの --quick オプション指定が役立ちます。この場合、少なくとも myisamchk を実行する前にバックアップを作成しておいてください。