このセクションでは、データ型または文字セットの処理方法に関する 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
はエラーをレポートしないはずです。