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
を実行できます。