MySQL 5.1 リファレンスマニュアル :: 12 SQL ステートメント構文 :: 12.5 データベース管理ステートメント :: 12.5.2 テーブル メンテナンス ステートメント :: 12.5.2.6 REPAIR TABLE 構文
« 12.5.2.5 OPTIMIZE TABLE 構文

12.5.2.7 RESTORE TABLE 構文 »
Section Navigation      [Toggle]
  • 12.5.2 テーブル メンテナンス ステートメント
  • 12.5.2.1 ANALYZE TABLE 構文
  • 12.5.2.2 BACKUP TABLE 構文
  • 12.5.2.3 CHECK TABLE 構文
  • 12.5.2.4 CHECKSUM TABLE 構文
  • 12.5.2.5 OPTIMIZE TABLE 構文
  • 12.5.2.6 REPAIR TABLE 構文
  • 12.5.2.7 RESTORE TABLE 構文

12.5.2.6. REPAIR TABLE 構文

REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
    tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE は破損された可能性があるテーブルを修復します。これはデフォルトで、myisamchk --recover tbl_name と同じ効果を持っています。REPAIR TABLE は MyISAM と ARCHIVE テーブルに対して機能します。MySQL 5.1.9 から、REPAIR は CSV テーブルにも有効になりました。 項13.4. 「MyISAM ストレージエンジン」、項13.10. 「ARCHIVE ストレージエンジン」、そして 項13.11. 「CSV ストレージエンジン」 を参照してください。

このステートメントはテーブルに SELECT と INSERT 権限を要求します。

通常は、このステートメントは一度も実行する必要はありません。しかし、もし大変な失敗をしてしまった時は REPAIR TABLE を利用すると全てのデータを MyISAM テーブルから取り戻す事ができます。もしテーブルが頻繁に破損する場合は、REPAIR TABLE を利用する必要性を減らす為にその原因を見つける努力が必要です。項B.1.4.2. 「What to Do If MySQL Keeps Crashing」 と 項13.4.4. 「MyISAM テーブルの問題点」 を参照して下さい。

警告:もし REPAIR TABLE 操作の最中にサーバが停止してしまったら、再起動した直後に、他の操作をする前にすぐにもう一度 REPAIR TABLE ステートメントを実行しなければいけません。(バックアップを作成してスタートさせるのが良いでしょう。)最悪の場合、データ ファイルの情報を何も持たない新しい綺麗なインデックス ファイルを得て、その次に行う操作によってデータ ファイルが上書きされてしまう事もあるでしょう。実際に起こる可能性は低い事ですが、起こり得るシナリオです。

REPAIR TABLE は次のカラムを利用して結果セットを返します。

カラム 値
Table テーブル名
Op いつも repair
Msg_type status、error、info、または warning の1つ
Msg_text メッセージ

REPAIR TABLE ステートメントは各修復済テーブルにたくさんの情報行を作成する可能性があります。最後の行は status と Msg_test の Msg_type 値を持ち、Msg_text は通常 OK になります。もし 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 によって行われた物と似ています。

REPAIR TABLE に有効な USE_FRM モードもあります。もし .MYI インデックス ファイルがなくなっていたり、そのヘッダが破損していたらこれを利用してください。このモードでは、MySQL は .frm ファイルからの情報を利用して .MYI ファイルを再作成します。この種類の修復は myisamchk ではできません。注意:このモードは、通常の REPAIR モードを利用できない時 のみ 利用してください。.MYI ヘッダは REPAIR ... USE_FRM 内で失われた重要なテーブル メタデータ(具体的には、現在の AUTO_INCREMENT 値と Delete link)を含んでいます。この情報は .MYI ファイル内にも格納されているので、テーブルが圧縮された時には USE_FRM を利用しないでください。

REPAIR TABLE ステートメントは、任意の NO_WRITE_TO_BINLOG キーワード(またはそのエイリアス LOCAL)が利用されない限り、バイナリ ログに書きこまれます。これは、複製マスタとして機能している MySQL サーバ上で利用される REPAIR TABLE ステートメントが、複製スレーブにデフォルトで複製される為に行われます。

Copyright © 1997, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices
Top / Previous / Next / Up / Table of Contents
© 2010, Oracle Corporation and/or its affiliates