REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE は、特定のストレージエンジンに対してのみ、破損している可能性のあるテーブルを修復します。
このステートメントには、このテーブルに対する SELECT および INSERT 権限が必要です。
通常、REPAIR TABLE を実行する必要はありませんが、災害が発生した場合は、このステートメントを使用すると MyISAM テーブルからすべてのデータをリストアできる可能性があります。 テーブルが頻繁に破損する場合は、その原因を見つけることにより、REPAIR TABLE を使用する必要がなくなるようにしてください。 セクションB.3.3.3「MySQL が繰り返しクラッシュする場合の対処方法」およびセクション16.2.4「MyISAM テーブルの問題点」を参照してください。
REPAIR TABLE はテーブルをチェックして、アップグレードが必要かどうかを確認します。 アップグレードが必要な場合は、CHECK TABLE ... FOR UPGRADE と同じルールに従ってアップグレードを実行します。 詳細は、セクション13.7.3.2「CHECK TABLE ステートメント」を参照してください。
テーブルの修復操作を実行する前に、そのテーブルのバックアップを作成してください。状況によっては、この操作のためにデータ損失が発生することがあります。 考えられる原因としては、ファイルシステムのエラーなどがありますがこれに限りません。 第7章「バックアップとリカバリ」を参照してください。
REPAIR TABLE操作中にサーバーが終了した場合は、再起動後、テーブルに対して別のREPAIR TABLEステートメントをすぐに実行してから、ほかの操作を実行することが不可欠です。 最悪の場合は、データファイルに関する情報のない新しいクリーンなインデックスファイルが生成されており、実行する次の操作によってデータファイルが上書きされる可能性があります。 この状況はめったに発生しませんが、最初にバックアップを作成することの価値を強調している、可能性のあるシナリオです。ソース上のテーブルが破損し、そのテーブルで
REPAIR TABLEを実行した場合、元のテーブルに対する変更はレプリカに伝播されません。
REPAIR TABLE は、MyISAM、ARCHIVE および CSV テーブルに対して機能します。 MyISAM テーブルの場合、デフォルトでは myisamchk --recover tbl_name と同じ効果があります。 このステートメントはビューでは機能しません。
REPAIR TABLE は、パーティション化されたテーブルに対してサポートされています。 ただし、パーティション化されたテーブルに対して、このステートメントで USE_FRM オプションを使用することはできません。
ALTER TABLE ... REPAIR PARTITION を使用すると、1 つ以上のパーティションを修復できます。詳細は、セクション13.1.9「ALTER TABLE ステートメント」およびセクション24.3.4「パーティションの保守」を参照してください。
-
NO_WRITE_TO_BINLOGまたはLOCALデフォルトでは、
REPAIR TABLEステートメントはレプリカにレプリケートされるようにバイナリログに書き込まれます。 ロギングを抑制するには、オプションのNO_WRITE_TO_BINLOGキーワード、またはそのエイリアスLOCALを指定します。 -
QUICKQUICKオプションを使用した場合、REPAIR TABLEはデータファイルではなく、インデックスファイルのみを修復しようとします。 このタイプの修復は、myisamchk --recover --quick によって実行される修復と同様です。 -
EXTENDEDEXTENDEDオプションを使用した場合、MySQL はソートしながら 1 回につき 1 つのインデックスを作成する代わりに、1 行ごとにインデックスを作成します。 このタイプの修復は、myisamchk --safe-recover によって実行される修復と同様です。 -
USE_FRMUSE_FRMオプションは、.MYIインデックスファイルがない場合や、そのヘッダーが破損している場合に使用できます。 このオプションは、.MYIファイルヘッダーの情報を信頼せず、データディクショナリの情報を使用して再作成するように MySQL に指示します。 この種類の修復は、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はテーブルをチェックして、アップグレードが必要かどうかを確認しません。
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 では、--max-record-length など、REPAIR TABLE でサポートされていないオプションを使用することもできます。)
REPAIR TABLE テーブルは、古い破損したファイルから新しく作成されたファイルへのテーブル統計のコピー中に発生したすべてのエラーをキャッチしてスローします。 たとえば、.MYD または .MYI ファイルの所有者のユーザー ID が mysqld プロセスのユーザー ID と異なる場合、REPAIR TABLE では、root ユーザーが mysqld を起動しないかぎり、「ファイルの所有権を変更できません」というエラーが生成されます。
REPAIR TABLE では、5.6.4 より前の形式 (TIME、DATETIME および TIMESTAMP カラムで小数秒精度をサポートしていない) の古い時間的カラムが含まれており、avoid_temporal_upgrade システム変数が無効になっている場合、テーブルがアップグレードされます。 avoid_temporal_upgrade が有効な場合、REPAIR TABLE はテーブルに存在する古い時間的カラムを無視し、それらをアップグレードしません。
このような時間的カラムを含むテーブルをアップグレードするには、REPAIR TABLE を実行する前に avoid_temporal_upgrade を無効にします。
特定のシステム変数を設定することによって、REPAIR TABLE のパフォーマンスを向上させることができる可能性があります。 セクション8.6.3「REPAIR TABLE ステートメントの最適化」を参照してください。