テーブル メンテナンス ステートメント

BACKUP TABLE tbl_name [, tbl_name] ... TO '/path/to/backup/directory'

3. CHECK TABLE 構文

CHECK TABLE tbl_name [, tbl_name] ... [option] ...

option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

CHECK TABLE はテーブルのエラーを確認します。CHECK TABLE は MyISAM、InnoDB、そして ARCHIVE テーブルにのみ機能します。MySQL 5.1.9 から、CHECK は CSV テーブルにも有効になりました。 項13.11. 「CSV ストレージエンジン」 を参照してください。MyISAM テーブルに対しては、キー統計もまた更新されます。

CHECK TABLE は、既に存在していないビュー定義内で参照されるテーブルなどのような、ビューの問題も確認できます。

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

ステートメントは各確認済テーブルにたくさんの情報行を作成する可能性がある事に注意してください。最後の行は status の Msg_type 値を持ち、Msg_text は通常 OK になります。もし OK か Table is already up to date が得られなければ、通常はテーブルの修復を起動する必要があります。詳しくは 項 「テーブル保守とクラッシュ リカバリ」 を参照してください。Table is already up to date は、そのテーブルのストレージ エンジンが、そのテーブルを確認する必要は無いと指示しているという意味です。

FOR UPGRADE オプションは、名づけられたテーブルが現在の MySQL バージョンと互換性があるか確認します。このオプションは MySQL 5.1.7 で追加されました。サーバは FOR UPGRADE を利用し、作成された時以降、各テーブルに対してデータ タイプやインデックスに互換性の無い変更があったかどうかを確認します。もし無ければ、その確認は成功です。反対に、もし非適応性があれば、サーバはテーブルに対して総確認を行います。(少々時間がかかります。)もし総確認が成功すれば、サーバはテーブルの .frm ファイルに現在の MySQL バージョン番号をマークします。.frm ファイルをマークする事で、同じバージョンのサーバによるそのテーブルの今後の確認が早くなる事が保証されます。

データタイプの格納フォーマットが変更されたか、そのソート順が変更された為に、非適合性が発生する可能性があります。私たちの目的はそれらの変更を避ける事ですが、時として各リリースの間に、非適合性よりもさらに深刻である問題を修正する事の方が大切な事もあります。

現在は、FOR UPGRADE でこれらの非適合性が見つかっています。

それ以外のチェックポイントは次のテーブルに表されています。これらのオプションは MyISAM テーブルの確認だけに適応し、InnoDB テーブルとビューでは無視されます。

もし QUICK、MEDIUM、または EXTENDED のどのオプションも指定されなければ、動的フォーマットである MyISAM テーブルのデフォルトの確認タイプは MEDIUM になります。これは、テーブル上で myisamchk --medium-check tbl_name を起動させるのと同じ結果になります。CHANGED か FAST が指定されない限り、静的フォーマットの MyISAM テーブルのデフォルトの確認タイプは、MEDIUM です。その場合、デフォルトは QUICK です。行はめったに破壊されないので、CHANGED と FAST の行スキャンは省かれます。

テーブルが正しく閉じられているかどうかの確認の為に簡単なチェックを行っている次の例のように、確認オプションを組み合わせる事も可能です。

CHECK TABLE test_table FAST QUICK;

注意:場合によっては CHECK TABLE でテーブルが変更されます。これは、テーブルが 「corrupted」 や 「not closed properly」 と印されているにも関わらず、CHECK TABLE がそのテーブル内に何の問題も発見できない時に起こります。この場合、CHECK TABLE はテーブルに OK の印をつけます。

もしテーブルが破損すると、その問題はデータ部分ではなく、ほとんどインデックス内にあるでしょう。これまでに紹介された全ての確認タイプはインデックスをくまなく確認するので、ほとんどのエラーを見つける事ができるはずです。

もし OK であると思われるテーブルを確認したければ、確認オプションは利用しない、または利用するのであれば QUICK オプションを利用しなければいけません。急いでいる為、QUICK がデータ ファイル中に何のエラーも発見しないかもしれないという小さいリスクを負う事ができる場合には、後者を利用してください。(ほとんどの場合、通常の利用条件下であれば、MySQL はデータ ファイル中に何らかのエラーを発見するはずです。その場合、そのテーブルは 「corrupted」 と印が付けられ、修復されるまでは利用できなくなります。)

FAST と CHANGED は、テーブルを頻繁に確認したい場合に、スクリプト(例えば、cron から実行されるように)から利用されるようになっています。ほとんどの場合、FAST は CHANGED より好まれます。(MyISAM コード内にバグを見つけた可能性がある場合のみ、この方法は好ましくありません。)

通常確認を起動した後で、MｙSQL が行を更新したりキーで行を見つけたりする時に、テーブルから変なエラーが発生する場合のみEXTENDED が利用されます。これは通常確認が成功した場合は、めったに起こらないでしょう。

CHECK TABLE によって報告されたいくつかの問題は自動的に修復されません。

4. CHECKSUM TABLE 構文

CHECKSUM TABLE tbl_name [, tbl_name] ... [ QUICK | EXTENDED ]

CHECKSUM TABLE はテーブル チェックサムを報告します。

QUICK を利用すると、ライブ テーブル チェックサムが有効であればそれが報告され、有効でなければ NULL を利用できます。これはとても速いです。ライブ チェックサムは、テーブルを作成した時に CHECKSUM=1 テーブル オプションを指定する事によって有効になります。これは現在は MyISAM テーブルにだけサポートされています。詳しくは 項 「CREATE TABLE 構文」 を参照してください。

EXTENDED を利用すると、テーブル全体が一行ごとに読まれ、チェックサムが計算されます。 大きいテーブルでは時間がかかります。

もし QUICK と EXTENDED のどちらも指定されない場合、テーブル ストレージ エンジンがライブ チェックサムをサポートし、またそうでない場合にはテーブルをスキャンするのであれば、MySQL がライブ チェックサムを返します。

存在しないテーブルに対しては、CHECKSUM TABLE は NULL を返し、警告を生成します。

チェックサムの値はテーブル行フォーマットによって決まります。もし行フォーマットが変更されれば、チェックサムもまた変更されます。例えば、VARCHAR の格納フォーマットは MySQL 4.1 と 5.0 の間に変更されたので、もし4.1のテーブルが MySQL 5.0 にアップグレードされると、チェックサム値も変更されるでしょう。

5. OPTIMIZE TABLE 構文

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

もしテーブルの大部分を削除したり、変数長行で何箇所もテーブルを変更した場合は(VARCHAR、VARBINARY、BLOB、または TEXT カラムを持つテーブル)、OPTIMIZE TABLE を利用しなければいけません。

削除された行はリンクされたリスト内で保存され、後続の INSERT 操作は古い行の位置を再利用します。使用されていないスペースの再要求をし、データ ファイルをデフラグするには OPTIMIZE TABLE を利用する事ができます。

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

ほとんどの設定で、OPTIMIZE TABLE を利用する必要は全くありません。可変長行の更新を頻繁にするとしても、特定のテーブルに対してだけ、この作業を週に一度、または月に一度以上する必要はありません。

OPTIMIZE TABLE は MyISAM と InnoDB テーブルに対して のみ 機能します。これは、NDB ディスク データ テーブルを含むその他のストレージ エンジンを利用して作成されたテーブルには機能 しません。

MyISAM テーブルに対しては、OPTIMIZE TABLE は次のように機能します。

InnoDB テーブルに対しては、 インデックス統計とクラスタされたインデックス内の使用されていないフリー スペースを更新する為にテーブルを復元する ALTER TABLE に OPTIMIZE TABLE がマップされます。

--skip-new か --safe-mode オプションを利用して mysqld をスタートさせる事で、OPTIMIZE TABLE が別のストレージ エンジン上で機能させる事ができます。この場合、OPTIMIZE TABLE は単に ALTER TABLE にマップされます。

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

MySQL は OPTIMIZE TABLE が起動している最中にテーブルをロックするという事に注意してください。

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

OPTIMIZE TABLE は、POINT カラム上の空間インデックスのような、R-tree インデックスをソートしません。(バグ #23578)

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. 「What to Do If MySQL Keeps Crashing」 と 項 「MyISAM テーブルの問題点」 を参照して下さい。

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

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

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 ステートメントが、複製スレーブにデフォルトで複製される為に行われます。

7. RESTORE TABLE 構文

RESTORE TABLE tbl_name [, tbl_name] ... FROM '/path/to/backup/directory'

RESTORE TABLE は BACKUP TABLE で作成されたバックアップからテーブルを復旧します。ディレクトリは、完全なパス名として指定されなければいけません。

既存テーブルは上書きされません。もしそのようなテーブルを修復させようとするとエラーが発生します。BACKUP TABLE と同じで、RESTORE TABLE は現在 MyISAM テーブルにしか機能しません。修復されたテーブルはマスタからスレーブに複製されません。

各テーブルのバックアップは、その .frm フォーマット ファイルと .MYD データ ファイルで構成されています。修復操作はそれらのファイルを修復し、そして .MYI インデックス ファイルを再構築する為にそれらを利用します。修復操作は、インデックスを再構築する必要がある為、バックアップ作業よりも時間がかかります。テーブルが長いインデックスを持っていれば、その分時間も長くかかります。

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