Skip navigation links
8.5.2.7 RESTORE TABLE 構文 »
Section Navigation      [Toggle]

8.5.2.6. REPAIR TABLE 構文

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

REPAIR TABLE は破損された可能性があるテーブルを修復します。デフォルトでは、これには myisamchk --recover tbl_name と同じ効果があります。REPAIR TABLE は MyISAM と ARCHIVE テーブルに対して機能します。MySQL 5.1.9 から、REPAIR は CSV テーブルにも有効になりました。The MyISAM Storage Engine、The ARCHIVE Storage Engine、そして The CSV Storage Engine を参照してください。

このステートメントはテーブルに SELECT と INSERT 権限を要求します。

MySQL 5.1.27 からは、REPAIR TABLE はパーティション化されたテーブルに対してもサポートされています。ただし、パーティション化されたテーブル上で、USE_FRM オプションをこのステートメントで使用することはできません。

また、MySQL 5.1.27 からは、ALTER TABLE ... REPAIR PARTITION を使用して 1 つ以上のパーティションを修復することもできます。詳細については、項8.1.7. 「ALTER TABLE 構文」 および Maintenance of Partitions を参照してください。

通常、REPAIR TABLE を実行する必要はありません。ただし、障害が発生した場合は、このステートメントによって MyISAM テーブルからすべてのデータが復元される可能性が高くなります。 もしテーブルが頻繁に破損する場合は、REPAIR TABLE を利用する必要性を減らすためにその原因を見つける努力が必要です。What to Do If MySQL Keeps Crashing、MyISAM Table Problems を参照してください。

注意

テーブルの修復操作を実行する前に、テーブルのバックアップを作成することをお勧めします。状況によっては、この操作のためにデータ損失が発生することがあります。考えられる原因としては、ファイルシステムのエラーなどがあります。

警告

REPAIR TABLE 操作中にサーバーが停止した場合は、再起動したあと、そのテーブルに対してほかの何らかの操作を実行する前に、もう一度 REPAIR TABLE ステートメントをただちに実行することが不可欠です。最悪の場合、データファイルの情報を何も持たない新しい綺麗なインデックスファイルを得て、その次に行う操作によってデータファイルが上書きされてしまうこともあるでしょう。この状況はめったに発生しませんが、最初にバックアップを作成する価値を強調する、可能性のあるシナリオです。

REPAIR TABLE は、次のカラムを含む結果セットを返します。

カラム 値
テーブル テーブル名
Op いつも repair
Msg_type status、error、info、または warning
Msg_text 情報メッセージ

REPAIR TABLE ステートメントは各修復済テーブルにたくさんの情報行を作成する可能性があります。最後の行の Msg_type 値は status であり、Msg_test は通常 OK になります。MyISAM テーブルに対して OK が表示されない場合は、myisamchk --safe-recover を使用して修復してみてください。(REPAIR TABLE によって、myisamchk のすべてのオプションが実装されるわけではありません。) myisamchk --safe-recover を利用すると、--max-record-length のような REPAIR TABLE がサポートしていないオプションを利用することができます。

QUICK オプションを使用した場合、REPAIR TABLE はインデックスツリーのみを修復しようとします。この型の修正は myisamchk --recover --quick によって行われたものと似ています。

EXTENDED オプションを使用した場合、MySQL はソートしながら一度に 1 つのインデックスを作成する代わりに、1 行ごとにインデックスを作成します。この型の修正は myisamchk --recover --quick によって行われたものと似ています。

.MYI インデックスファイルがない場合や、そのヘッダーが破損している場合は、USE_FRM オプションを使用できます。このオプションは MySQL に、.MYI ファイルヘッダー内の情報を信頼せずに、.frm ファイルからの情報を使用してファイルヘッダーを再作成するよう指示します。この種類の修復は myisamchk ではできません。

注意

通常の REPAIR モードを使用できない場合は、USE_FRM オプションのみを使用します。サーバーに .MYI ファイルを無視するよう指示すると、.MYI に格納されている重要なテーブルメタデータが修復プロセスから使用できなくなるため、有害な結果を招く場合があります。

  • 現在の AUTO_INCREMENT 値は失われます。

  • テーブル内の削除されたレコードへのリンクは失われます。つまり、削除されたレコードの空き領域は、それ以降も占有されずに残ります。

  • .MYI ヘッダーは、テーブルが圧縮されているかどうかを示します。サーバーがこの情報を無視すると、テーブルが圧縮されていることがわからないため、修復によってテーブルコンテンツの変更または損失が発生する場合があります。つまり、圧縮テーブルでは USE_FRM を使用ないようにしてください。いずれにしても、これは必須ではありません。圧縮テーブルは読み取り専用であるため、破損することはありません。

注意

MySQL 5.1.25 の時点では、現在実行中のバージョンとは異なるバージョンの MySQL サーバーによって作成されているテーブルに対して USE_FRM を使用した場合、REPAIR TABLE はテーブルの修復を試みません。この場合、REPAIR TABLE によって返される結果セットには、Msg_type 値が error で、Msg_text 値が Failed repairing incompatible .FRM file である行が含まれています。

MySQL 5.1.25 より前のバージョンでは、テーブルが、異なるバージョンの MySQL サーバーによって作成されている場合は USE_FRM を使用しないでください。使用すると、テーブル内のすべての行が損失するおそれがあります。サーバーから次のメッセージが返されたあとに USE_FRM を使用することは特に危険です。 

Table upgrade required. Please do
"REPAIR TABLE `tbl_name`"
or dump/reload to fix it!

USE_FRM が使用されていない場合、REPAIR TABLE はテーブルを確認して、アップグレードが必要かどうかを調べます。アップグレードが必要な場合は、CHECK TABLE ... FOR UPGRADE と同じ規則に従ってアップグレードを実行します。詳細については、項8.5.2.3. 「CHECK TABLE 構文」 を参照してください。MySQL 5.1.25 の時点では、USE_FRM が指定されていない REPAIR TABLE によって、.frm ファイルが現在のバージョンにアップグレードされます。

デフォルトでは、REPAIR TABLE ステートメントはレプリケーションスレーブに複製されるように、バイナリログに書き込まれます。ロギングは、オプションの NO_WRITE_TO_BINLOG キーワードまたはそのエイリアス LOCAL を使用して抑制できます。