13.7.2.5 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、および CSV の各テーブルのみに適用されます。セクション15.2「MyISAM ストレージエンジン」、セクション15.5「ARCHIVE ストレージエンジン」、およびセクション15.4「CSV ストレージエンジン」を参照してください。

このステートメントには、このテーブルに対する SELECT および INSERT 権限が必要です。

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

MySQL 5.6.11 でのみ、このステートメントを発行する前に、gtid_next を AUTOMATIC に設定する必要があります。(Bug #16062608、Bug #16715809、Bug #69045)

ALTER TABLE ... REPAIR PARTITION を使用すると、1 つ以上のパーティションを修復できます。詳細は、セクション13.1.7「ALTER TABLE 構文」およびセクション19.3.4「パーティションの保守」を参照してください。

通常、REPAIR TABLE を実行する必要はありませんが、災害が発生した場合は、このステートメントを使用すると MyISAM テーブルからすべてのデータをリストアできる可能性があります。テーブルが頻繁に破損する場合は、その原因を見つけることにより、REPAIR TABLE を使用する必要がなくなるようにしてください。セクションB.5.4.2「MySQL が繰り返しクラッシュする場合の対処方法」およびセクション15.2.4「MyISAM テーブルの問題点」を参照してください。

注意

テーブルの修復操作を実行する前に、そのテーブルのバックアップを作成してください。状況によっては、この操作のためにデータ損失が発生することがあります。考えられる原因としては、ファイルシステムのエラーなどがありますがこれに限りません。第7章「バックアップとリカバリ」を参照してください。

警告

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

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

カラム	値
Table	テーブル名
Op	常に repair
Msg_type	status、error、info、note、または warning
Msg_text	情報メッセージ

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

QUICK オプションを使用した場合、REPAIR TABLE はデータファイルではなく、インデックスファイルのみを修復しようとします。このタイプの修復は、myisamchk --recover --quick によって実行される修復と同様です。

EXTENDED オプションを使用した場合、MySQL はソートしながら 1 回につき 1 つのインデックスを作成する代わりに、1 行ごとにインデックスを作成します。このタイプの修復は、myisamchk --safe-recover によって実行される修復と同様です。

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

注記

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

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

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

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

注意

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

USE_FRM が使用されていない場合、REPAIR TABLE はテーブルをチェックして、アップグレードが必要かどうかを確認します。アップグレードが必要な場合は、CHECK TABLE ... FOR UPGRADE と同じルールに従ってアップグレードを実行します。詳細は、セクション13.7.2.2「CHECK TABLE 構文」を参照してください。USE_FRM のない REPAIR TABLE は、.frm ファイルを現在のバージョンにアップグレードします。

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

重要

マスター上のテーブルが破損し、そのテーブルに対して REPAIR TABLE を実行した場合、その結果としての元のテーブルへの変更はスレーブに伝播されません。

特定のシステム変数を設定することによって、REPAIR TABLE のパフォーマンスを向上させることができる可能性があります。セクション8.6.3「REPAIR TABLE ステートメントの速度」を参照してください。

REPAIR TABLE テーブルは、古い破損したファイルから新しく作成されたファイルへのテーブル統計のコピー中に発生したすべてのエラーをキャッチしてスローします。たとえば、.frm、.MYD、または .MYI ファイルの所有者のユーザー ID が mysqld プロセスのユーザー ID と異なる場合は、mysqld が root ユーザーによって起動されていないかぎり、REPAIR TABLE は "cannot change ownership of the file" エラーを生成します。