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

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

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

MySQL 5.6.11 でのみ、このステートメントを発行する前に、gtid_nextAUTOMATIC に設定する必要があります。(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 statuserrorinfonote、または warning
Msg_text 情報メッセージ

REPAIR TABLE ステートメントによって、修復されたテーブルごとに多数の情報行が生成される可能性があります。最後の行には statusMsg_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 と異なる場合は、mysqldroot ユーザーによって起動されていないかぎり、REPAIR TABLE は "cannot change ownership of the file" エラーを生成します。


User Comments
  Posted by shimon doodkin on September 14, 2009
false positive case after upgrade

the character sets dir configuration was missing and no tables repair was needed.

i had a strange issue.
i had upgraded mysql from public repository with apt-get
and after then had disk full error and had to restart.
after repairing the disk full error i have discovered the data selected from tables is gibberish.
in phpmyadmin the type of all tables was VIEW
and they all ware corrupt even if i repair them or optimize or check... and when i repair it with myisamchk it does nothing.
just shows :
myisamchk -eron emaillist, the errors:
- recovering (with sort) MyISAM-table 'emaillist'
Data records: 4255
- Fixing index 1
Found link that points at -1735598930481103523 (outside data file) at 27888
Found block that points outside data file at 268252
Found block that points outside data file at 268572
Found block that points outside data file at 268844
Found block that points outside data file at 268916

and nothing was changed after the repair.

in phpmyadmin when i click on a table it selected SHOW FULL COLUMNS and it showd an error similar to: the table is corrupt unknown COLLATIONS #16 error #1273

i have started to search, where are those collation numbers came from, and found that in mysql schema database there is a collations table
and my number 16 was missing
and i saw that the list is suspiciously small.
when i ran 'mysql --help' there was no charset directory

the solution was to set the in my.cnf
[mysqld]
character-sets-dir=/usr/share/mysql/charsets

and it worked like a charm
  Posted by Victor Praigs on March 1, 2014
You can repair & restore your corrupt MySQL database by MySQL Repair Toolbox. It is read only in nature and successful restore table corruption in MySQL database. You can download free demo version to see the preview of your corrupt database.

http://www.mysql.repairtoolbox.com/
Sign Up Login You must be logged in to post a comment.