13.7.2.2 CHECK TABLE 構文

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

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

CHECK TABLE は、1 つまたは複数のテーブルをエラーがないかどうかチェックします。CHECK TABLE は、InnoDB、MyISAM、ARCHIVE、および CSV テーブルに対して機能します。MyISAM テーブルの場合は、キー統計の更新も実行されます。

テーブルをチェックするには、それに対する何らかの権限が必要です。

CHECK TABLE はまた、ビューをチェックして、そのビュー定義で参照されているテーブルが存在しなくなっているなどの問題がないかどうかを調べることもできます。

CHECK TABLE はパーティション化されたテーブルに対してサポートされているため、ALTER TABLE ... CHECK PARTITION を使用して 1 つ以上のパーティションをチェックできます。詳細は、セクション13.1.7「ALTER TABLE 構文」およびセクション19.3.4「パーティションの保守」を参照してください。

MySQL 5.6.11 でのみ、このステートメントを発行する前に、gtid_next を AUTOMATIC に設定する必要があります。(Bug #16062608、Bug #16715809、Bug #69045)

出力

CHECK TABLE は、次のカラムを含む結果セットを返します。

カラム	値
Table	テーブル名
Op	常に check
Msg_type	status、error、info、note、または warning
Msg_text	情報メッセージ

このステートメントによって、チェックされたテーブルごとに多数の情報行が生成される可能性があります。最後の行には status の Msg_type 値が含まれ、Msg_text は通常 OK になります。OK または Table is already up to date が得られない場合は通常、そのテーブルの修復を実行するべきです。セクション7.6「MyISAM テーブルの保守とクラッシュリカバリ」を参照してください。Table is already up to date は、そのテーブルのストレージエンジンがテーブルのチェックは必要ないと判断したことを示します。

バージョン互換性のチェック

FOR UPGRADE オプションは、指定されたテーブルが現在のバージョンの MySQL と互換性があるかどうかをチェックします。FOR UPGRADE を指定すると、サーバーは各テーブルをチェックして、テーブルの作成後にそのテーブルのいずれかのデータ型またはインデックスで互換性のない変更が発生しているかどうかを判定します。発生していない場合は、チェックが成功します。それ以外で、非互換性の可能性がある場合、サーバーはそのテーブルに対して完全なチェックを実行します (これには、ある程度時間がかかることがあります)。完全なチェックが成功した場合、サーバーは、そのテーブルの .frm ファイルを現在の MySQL バージョン番号でマークします。.frm ファイルをマークすると、このテーブルに対する同じバージョンのサーバーによるそれ以降のチェックが確実に速くなります。

データ型のストレージフォーマットが変更されたか、またはそのソート順序が変更されたために非互換性が発生する可能性があります。弊社の目的はそれらの変更を避けることですが、各リリースの間の非適合性よりもさらに深刻な問題を修正するために必要である場合もあります。

現在、FOR UPGRADE では、次の非互換性が検出されています。

• InnoDB および MyISAM テーブルの TEXT カラム内の最後の領域のインデックス順序が MySQL 4.1 と 5.0 の間で変更されました。

• 新しい DECIMAL データ型のストレージ方法が MySQL 5.0.3 と 5.0.5 の間で変更されました。

• テーブルが、現在実行しているものとは異なるバージョンの MySQL サーバーによって作成された場合、FOR UPGRADE は、そのテーブルに互換性のないバージョンの .frm ファイルが含まれていることを示します。この場合、CHECK TABLE によって返される結果セットには、Msg_type 値が error で、Msg_text 値が Table upgrade required. Please do "REPAIR TABLE `tbl_name`" to fix it! である行が含まれています。

• 文字セットまたは照合順序に対して、テーブルインデックスの再構築が必要な変更が加えられる場合があります。これらの変更や、それが FOR UPGRADE によっていつ検出されるかの詳細は、セクション2.11.3「テーブルまたはインデックスの再構築が必要かどうかのチェック」を参照してください。

• YEAR(2) データ型は、MySQL 5.6.6 の時点では非推奨です。YEAR(2) カラムを含むテーブルの場合、CHECK TABLE では、YEAR(2) を YEAR(4) に変換する REPAIR TABLE が推奨されます。

データ一貫性のチェック

指定できるその他のチェックオプションを次の表に示します。これらのオプションはストレージエンジンに渡されますが、そこで使用される場合とされない場合があります。

型	意味
QUICK	正しくないリンクをチェックするための行のスキャンを行いません。InnoDB および MyISAM テーブルとビューに適用されます。
FAST	正しく閉じられていないテーブルのみを検査します。MyISAM テーブルとビューにのみ適用されます。InnoDB では無視されます。
CHANGED	最後のチェック以降に変更されたか、または正しく閉じられていないテーブルのみをチェックします。MyISAM テーブルとビューにのみ適用されます。InnoDB では無視されます。
MEDIUM	削除されたリンクが有効であることを検証するために行をスキャンします。また、行のキーチェックサムも計算し、キーの計算されたチェックサムを使用してこれを検証します。MyISAM テーブルとビューにのみ適用されます。InnoDB では無視されます。
EXTENDED	行ごとにすべてのキーの完全なキールックアップを実行します。これにより、テーブルの 100% の整合性が保証されますが、長い時間がかかります。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 によってテーブルが変更されます。これは、テーブルが「破損している」または「正しく閉じられていない」としてマークされているが、CHECK TABLE でそのテーブル内に何も問題が見つからなかった場合に発生します。この場合、CHECK TABLE はそのテーブルを正常としてマークします。

テーブルが破損している場合、もっとも可能性が高いのはデータ部分ではなく、インデックス内の問題です。前のチェックタイプはすべて、インデックスを徹底的にチェックするため、ほとんどのエラーが見つかるはずです。

正常と見なしているテーブルをチェックするだけの場合は、チェックオプションを使用しないか、または QUICK オプションを使用するようにしてください。後者は、急いでおり、かつ QUICK でデータファイル内のエラーが見つからないという非常に小さなリスクを負える場合に使用するようにしてください。(ほとんどの場合、通常の使用状況では、MySQL でデータファイル内のどのようなエラーも見つかります。見つかった場合、そのテーブルは「破損している」としてマークされ、修復されるまで使用できなくなります。)

FAST および CHANGED は主に、テーブルをときどきチェックする場合にスクリプトから使用される (たとえば、cron から実行される) ことを目的にしています。ほとんどの場合、FAST は CHANGED より優先されます。(優先されない唯一の場合は、MyISAM コード内にバグが見つかったのではないかと疑われるときです。)

EXTENDED は、通常のチェックを実行したが、MySQL が行を更新するか、またはキーで行を検索しようとすると引き続きテーブルで奇妙なエラーが発生する場合にのみ使用されます。通常のチェックが成功した場合、これはめったに発生しません。

CHECK TABLE ... EXTENDED を使用すると、クエリーオプティマイザによって生成される実行計画に影響を与える可能性があります。

CHECK TABLE によってレポートされる次のいくつかの問題は、自動的には修正できません。

• Found row where the auto_increment column has the value 0。

  これは、AUTO_INCREMENT インデックスカラムに値 0 が含まれている行がテーブル内に存在することを示します。(AUTO_INCREMENT カラムが 0 である行は、UPDATE ステートメントを使用してそのカラムを明示的に 0 に設定することによって作成できます。)

  これは、それ自体エラーではありませんが、そのテーブルをダンプしてリストアするか、またはそのテーブルに対して ALTER TABLE を実行しようとした場合に問題が発生する可能性があります。この場合、AUTO_INCREMENT カラムはその AUTO_INCREMENT カラムのルールに従って値を変更するため、重複キーエラーなどの問題が発生する可能性があります。

  この警告を解消するには、単純に、そのカラムを 0 以外の何からの値に設定するために UPDATE ステートメントを実行します。

InnoDB テーブル

次の注意事項は、InnoDB テーブルに適用されます。

• CHECK TABLE で InnoDB テーブルの問題が見つかった場合、サーバーはエラーの伝播を回避するためにシャットダウンする可能性があります。このエラーの詳細はエラーログに書き込まれます。

• CHECK TABLE は、InnoDB テーブルまたはインデックスに破損またはエラーを検出すると、エラーをレポートします。サーバーをシャットダウンすることはしません。MySQL 5.5 からは、そのインデックスまたはテーブルのそれ以上の使用を防ぐために、CHECK TABLE は通常、そのインデックスを破損しているとしてマークし、またそのテーブルも同様にマークする場合があります。

• CHECK TABLE は、セカンダリインデックス内のエントリ数の間違いを見つけた場合、エラーをレポートしますが、サーバーをシャットダウンしたり、ファイルへのアクセスを防いだりはしません。

• CHECK TABLE はインデックスページの構造を調査してから、各キーエントリを調査します。キーポインタをクラスタ化されたレコードに対して検証したり、BLOB ポインタのパスに従ったりはしません。

• InnoDB テーブルが file-per-table モードで独自の .ibd ファイル に格納されると、.ibd の最初の 3 つのページには、テーブルまたはインデックスデータではなくヘッダー情報が含まれます。CHECK TABLE ステートメントは、ヘッダーデータにのみ影響を与える不整合を検出しません。InnoDB .ibd ファイルの内容全体を検証するには、innochecksum コマンドを使用します。

• 大きな InnoDB テーブルに対して CHECK TABLE を実行すると、CHECK TABLE の実行中にほかのスレッドがブロックされる可能性があります。タイムアウトを回避するために、CHECK TABLE 操作の場合は、セマフォー待機のしきい値 (600 秒) が 2 時間 (7200 秒) 延長されます。InnoDB は、240 秒以上のセマフォー待機を検出すると、InnoDB モニターの出力をエラーログに出力し始めます。ロック要求がセマフォー待機のしきい値を超えて延長された場合、InnoDB はそのプロセスを中止します。セマフォー待機が完全にタイムアウトする可能性を回避するには、CHECK TABLE の代わりに CHECK TABLE QUICK を実行できます。