2.11.4 テーブルまたはインデックスの再作成または修復

このセクションでは、データ型または文字セットの処理方法に関する MySQL の変更後の、テーブルの再構築方法を説明します。たとえば、照合順序のエラーが修正され、その照合順序を使用する文字カラムのインデックスを更新するためにテーブルの再構築が必要になることがあります。(例については、セクション2.11.3「テーブルまたはインデックスの再構築が必要かどうかのチェック」を参照してください。)CHECK TABLE、mysqlcheck、または mysql_upgrade によって実行されるようなテーブルチェック操作によって示されるように、テーブルを修復またはアップグレードする必要がある場合があります。

テーブルを再構築する方法には、テーブルをダンプしてリロードする方法や、ALTER TABLE または REPAIR TABLE を使用する方法があります。REPAIR TABLE は MyISAM、ARCHIVE、および CSV の各テーブルのみに適用されます。

注記

バイナリ (インプレース) アップグレードまたはダウングレード後に、MySQL の異なるバージョンがテーブルを処理しないためにテーブルを再構築する場合は、ダンプしてリロードする方法を使用する必要があります。アップグレードまたはダウングレードの前に、元のバージョンの MySQL を使用してテーブルをダンプします。次に、アップグレードまたはダウングレードのあとに、テーブルをリロードします。

インデックスを再構築する目的のためだけにダンプしてリロードする方法を使ってテーブルを再構築する場合は、アップグレードまたはダウングレードの前でもあとでもダンプを実行できます。その場合でも、リロードはあとで行う必要があります。

テーブルをダンプしてリロードすることによって再構築するには、mysqldump を使用してダンプファイルを作成し、mysql でファイルをリロードします。

shell> mysqldump db_name t1 > dump.sql
shell> mysql db_name < dump.sql

単独のデータベース内のテーブルをすべて再構築する場合は、データベース名を、そのあとにテーブル名なしで指定します。

shell> mysqldump db_name > dump.sql
shell> mysql db_name < dump.sql

すべてのデータベース内のすべてのテーブルをリロードするには、--all-databases オプションを使用してください。

shell> mysqldump --all-databases > dump.sql
shell> mysql < dump.sql

ALTER TABLE でテーブルを再構築する場合は、「null」 変更を使用します。すなわち、すでに使用しているストレージエンジンを使用するように、テーブルを「変更」する ALTER TABLE ステートメントです。たとえば、t1 が InnoDB テーブルである場合、次のステートメントを利用します。

mysql> ALTER TABLE t1 ENGINE = InnoDB;

ALTER TABLE ステートメントで指定するストレージエンジンがわからない場合は、SHOW CREATE TABLE を使用してテーブル定義を表示します。

CHECK TABLE 操作でテーブルのアップグレードが必要であることが示されるために InnoDB テーブルを再構築する必要がある場合は、前述のように mysqldump を使用してダンプファイルを作成し、mysql でファイルをリロードします。CHECK TABLE 操作で、破損があることが示されたり InnoDB が失敗したりする場合は、innodb_force_recovery オプションを使用して InnoDB を再起動する方法について、セクション14.19.2「InnoDB のリカバリの強制的な実行」を参照してください。CHECK TABLE が遭遇している問題のタイプを理解するには、セクション13.7.2.2「CHECK TABLE 構文」の InnoDB に関する注記を参照してください。

MyISAM、ARCHIVE、または CSV テーブルについては、テーブルチェック操作で破損があることやアップグレードが必要なことが示された場合は、REPAIR TABLE を使用できます。たとえば、MyISAM テーブルを修復するには、次のステートメントを使用します。

mysql> REPAIR TABLE t1;

mysqlcheck --repair は、コマンド行で REPAIR TABLE ステートメントへのアクセスを提供します。--databases オプションまたは --all-databases オプションをそれぞれ使用して、特定のデータベースまたはすべてのデータベースのすべてのテーブルを修復できるため、テーブル修復の方法として、より便利な場合があります。

shell> mysqlcheck --repair --databases db_name ...
shell> mysqlcheck --repair --all-databases

MySQL 5.1.24 で、Bug #27877 に対する修正 (utf8_general_ci および ucs2_general_ci 照合順序を修正しました) によって導入された非互換性については、MySQL 5.1.62、5.5.21、および 5.6.5 で回避策が実装されています。これらのいずれかのバージョンにアップグレードしてから、影響を受ける各テーブルを次の方法のいずれかを使用して変換します。どの場合も、回避策には、影響されるカラムを utf8_general_mysql500_ci および ucs2_general_mysql500_ci 照合順序を使用するように変更することが含まれます。この照合順序では、元の 5.1.24 より前の utf8_general_ci および ucs2_general_ci の順序付けを維持します。

• テーブルファイルをそのまま残すバイナリアップグレード後に、影響を受けるテーブルを変換するには、新しい照合順序を使用するようにテーブルを変更します。テーブル t1 に 1 つまたは複数の問題のある utf8 カラムがあるとします。テーブルをテーブルレベルで変換するには、次のようなステートメントを使用します。

  ALTER TABLE t1
  CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

  カラム固有ベースで変更を適用するには、次のようなステートメントを使用します (COLLATE 句を除き、最初に指定されていたカラム定義を必ず繰り返します)。

  ALTER TABLE t1
  MODIFY c1 CHAR(N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;

• ダンプしてリロードする手順を使用してテーブルをアップグレードする場合は、mysqldump を使用してテーブルをダンプし、ダンプファイル内の CREATE TABLE ステートメントを新しい照合順序を使用するように変更して、テーブルをリロードします。

適切な変更を行うと、CHECK TABLE はエラーをレポートしないはずです。