このセクションでは、MyISAM テーブルへの myisamchk の使用方法について説明します。(拡張子： .MYI、.MYD)

MyISAM テーブルのチェックと修復には、CHECK TABLE や REPAIR TABLE などのステートメントを使用します (推奨)。詳細は、項12.5.2.3. 「CHECK TABLE 構文」 を参照してください。

テーブル破損の症状としては、クエリが予期せず中断したり、次のようなエラーが発生します。

perror nnn を実行すると、エラーの詳細情報を取得できます。nnn はエラー番号です。次の例は、perror を使用した、テーブルに問題があることを示す一般的なエラーです。

shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired

ノート： エラー 135（no more room in record file）とエラー 136 (no more room in index file) は、簡単に直せるエラーではありません。この場合、ALTER TABLE を使用して MAX_ROWS または AVG_ROW_LENGTH テーブル オプションを値を修正してください。

ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

現行のテーブル オプション値がわからない場合は、SHOW CREATE TABLE を使用します。

この 2 つ以外のエラーが出る場合は、テーブルを修復します。 myisamchk で検出するときに、発生するエラーの原因を正します。

修復プロセスには、4 つの段階があります。Unix では、mysqld を実行する Unix ユーザに読み取り権限があることを確認します（この確認を行うユーザにもこれらのファイルへのアクセス権が必要）。ファイルを修正する必要がある場合は、書き込み権限も必要です。

このセクションでは、項4.9.4.2. 「MyISAM テーブルのエラー チェック方法」 で説明しているテーブル チェックで失敗した場合、または myisamchk の拡張機能を使用する場合の修復作業について説明しています。

myisamchk で行うテーブル保守のオプションに関しては、項7.4. 「myisamchk — MyISAM テーブル メンテナンス ユーティリティ」 を参照してください。

コマンドラインからテーブルを修復する場合は、まず、mysqld サーバを停止します。ノート： リモート サーバで mysqladmin shutdown を実行するときは、mysqladmin を返しても、すべてのステートメント処理の停止、続いてすべてのインデックスの変更をディスクにフラッシュするまでの間、 mysqld が活動を続けます。

段階 1:テーブルのチェック

myisamchk *.MYI、または時間に余裕があれば myisamchk -e *.MYI を実行します。-s (silent) オプションを使用すると、不要な情報出力を抑制します。

mysqld サーバが停止している場合は、--update-state オプションを使用して myisamchk にテーブルで 「checked」 マークを付けるよう指定します。

myisamchk がエラーを返すテーブルだけを修復する場合は、段階 2 へ進みます。

チェック時に複雑なエラー（out of memory エラーなど）が発生した場合、あるいは myisamchk がクラッシュした場合、段階 3 へ進みます。

段階 2: 簡単で安全な修復

まず、myisamchk -r -q tbl_name を試行する。(-r -q は 「クイック リカバリ モード」 で実行するという意味。) これで、データ ファイルには触れずにインデックス ファイルの修復だけを行います。データ ファイルに必要なデータがすべて揃っていて、削除リンクがデータ ファイル内の正しい位置を指していれば、テーブルは正常に修復できます。この後は、次のテーブルの修復を開始します。失敗した場合は以下の手順を実行します。

ノート:

修復オペを高速化するには、myisamchk を実行するときの sort_buffer_size および key_buffer_size の変数の値を、利用可能システム メモリの 25 パーセント (1/4) で設定します。

修復時に複雑なエラー（out of memory エラーなど）が発生した場合、あるいは myisamchk がクラッシュした場合、段階 3 へ進みます。

段階 3: 困難な修復

インデックス ファイルの最初の 16KB ブロックが破損している、またはそこに不正な情報がある場合、あるいは、インデックス ファイルがない場合に、この段階に進みます。この場合、新しいインデックス ファイルを作成する必要があります。以下を実行してください。

そして、段階 2 に戻ります。これで、myisamchk -r -q が機能するはずです（無限ループにならないはずです）。

REPAIR TABLE tbl_name USE_FRM の SQL ステートメントを使用して、この手順を自動的に行うこともできます。REPAIR TABLE を使用すると、サーバがすべての作業を行うため、ユーティリティとサーバの間に不要なやり取りが起こる可能性はありません。項12.5.2.6. 「REPAIR TABLE 構文」 を参照してください。

段階 4: 非常に困難な修復

.frm という記述ファイルもクラッシュしている場合に、この手順に従います。ただし、テーブル作成後に記述ファイルが変更になることはないため、通常は発生しない状況です。