Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


このページは機械翻訳したものです。

13.7.3.5 REPAIR TABLE ステートメント

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 ストレージエンジンおよびパーティショニングサポート

REPAIR TABLE は、MyISAMARCHIVE および CSV テーブルに対して機能します。 MyISAM テーブルの場合、デフォルトでは myisamchk --recover tbl_name と同じ効果があります。 このステートメントはビューでは機能しません。

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

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

REPAIR TABLE のオプション
  • NO_WRITE_TO_BINLOG または LOCAL

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

  • QUICK

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

  • EXTENDED

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

  • USE_FRM

    USE_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 の出力

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 では、--max-record-length など、REPAIR TABLE でサポートされていないオプションを使用することもできます。)

REPAIR TABLE テーブルは、古い破損したファイルから新しく作成されたファイルへのテーブル統計のコピー中に発生したすべてのエラーをキャッチしてスローします。 たとえば、.MYD または .MYI ファイルの所有者のユーザー ID が mysqld プロセスのユーザー ID と異なる場合、REPAIR TABLE では、root ユーザーが mysqld を起動しないかぎり、「ファイルの所有権を変更できません」というエラーが生成されます。

テーブルの修復に関する考慮事項

REPAIR TABLE では、5.6.4 より前の形式 (TIMEDATETIME および TIMESTAMP カラムで小数秒精度をサポートしていない) の古い時間的カラムが含まれており、avoid_temporal_upgrade システム変数が無効になっている場合、テーブルがアップグレードされます。 avoid_temporal_upgrade が有効な場合、REPAIR TABLE はテーブルに存在する古い時間的カラムを無視し、それらをアップグレードしません。

このような時間的カラムを含むテーブルをアップグレードするには、REPAIR TABLE を実行する前に avoid_temporal_upgrade を無効にします。

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