REPAIR [NO_WRITE_TO_BINLOG | LOCAL] TABLEtbl_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
を使用して抑制できます。