REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE は MyISAM テーブルにのみ有効であり、このテーブルで myisamchk -r table_name を実行するのと同じです。

通常であれば、このコマンドを使用することはありませんが、障害が発生した場合、REPAIR TABLE を使用すれば、ほとんどの場合、MyISAM テーブルのすべてのデータを取り戻せます。テーブルが頻繁に破損するようであれば、その原因を突き止めて、REPAIR TABLE を使用する必要がなくなるようにしてください。 See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。 See 項7.1.3. 「MyISAM テーブルの問題」。

REPAIR TABLE は、破損した可能性のあるテーブルを修復します。このコマンドは、以下のカラムで構成されるテーブルを返します。

注意: このステートメントは、修復した各テーブルに関する多くの情報レコードを生成します。 正常な場合、Msg_type は status で、Msg_text は通常 OK になります。OK を得られない場合は、myisamchk --safe-recover でテーブルの修復を試みてください。REPAIR TABLE ではまだ myisamchk のすべてのオプションをカバーしていません。将来は、このコマンドをより柔軟性の高いものにする予定です。

QUICK を指定した場合、REPAIR TABLE はインデックスツリーだけを修復しようとします。

EXTENDED を使用すると、MySQL はソートごとにインデックスを生成するのではなく、レコードごとにインデックスを生成します。確実に圧縮される長い CHAR キーを使用している場合など、固定長キーをソートするよりこの方法の方が適しています。このタイプの修復は、myisamchk --safe-recover で実行される修復とほぼ同じです。

MySQL 4.0.2 から、REPAIR に USE_FRM モードが導入されています。 .MYI ファイルがない、またはそのヘッダが破損している場合にこのモードを使用します。 このモードでは、.frm ファイルの情報を使用してテーブルが再度作成されます。このような修復は、myisamchk ではできません。

警告: REPAIR TABLE を実行中に mysqld が終了してしまった場合、他のコマンドを実行する前にもう 1 回 REPAIR を必ず実行してください（もちろん、常にバックアップから開始することを推奨します）。最悪の場合、データファイルに関する情報がない新規のクリーンなインデックスファイルができることがあり、次のコマンドでデータファイルが上書きされてしまう可能性があります。これはあまりないことではありますが、可能性としてはあり得るので、注意が必要です。

MySQL 4.1.1 より前では、REPAIR コマンドはバイナリログに書き込まれません。MySQL 4.1.1 以降、任意の NO_WRITE_TO_BINLOG キーワード（またはそのエイリアスの LOCAL）を使用しない限り、このコマンドはバイナリログに書き込まれます。