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" エラーを生成します。