Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


14.11.6 オンライン DDL の実装の詳細

InnoDB テーブルに対する各 ALTER TABLE 操作は、次のいくつかの側面によって制御されます。

  • テーブルの物理表現への何らかの変更があるかどうか、またはそれが純粋に、テーブル自体を変更することなく実行できるメタデータへの変更であるかどうか。

  • テーブル内のデータの量が同じままか、増えているか、または減っているか。

  • テーブルデータ内の変更がクラスタ化されたインデックス、セカンダリインデックス、またはその両方に関連しているかどうか。

  • 変更されるテーブルとその他のテーブルの間に何らかの外部キー関係が存在するかどうか。このメカニクスは、foreign_key_checks 構成オプションが有効または無効のどちらになっているかによって異なります。

  • テーブルがパーティション化されているかどうか。ALTER TABLE のパーティション化句は 1 つ以上のテーブルに関連する低レベルの操作に変換され、これらの操作はオンライン DDL の通常のルールに従います。

  • テーブルデータをコピーする必要があるかどうか、テーブルをインプレースで再編成できるかどうか、またはその両方の組み合わせか。

  • テーブルに自動インクリメントカラムが含まれているかどうか。

  • ベースとなるデータベース操作の性質、または ALTER TABLE ステートメントで指定した LOCK 句によって、どのようなレベルのロックが必要とされるか。

このセクションでは、これらの要因が InnoDB テーブルでのさまざまな種類の ALTER TABLE 操作にどのような影響を与えるかについて説明します。

オンライン DDL のエラー状態

オンライン DDL 操作が失敗する可能性がある主な理由を次に示します。

  • LOCK 句が、特定のタイプの DDL 操作とは互換性のない低レベルのロック (SHARED または NONE) を指定している場合。

  • DDL 操作の初期および最終フェーズ中に短時間だけ必要な、テーブルに対する排他的ロックの取得を待機している間にタイムアウトが発生した場合。

  • インデックス作成中に MySQL がディスク上に一時的なソートファイルを書き込んでいる間に tmpdir ファイルシステムのディスク領域が不足した場合。

  • ALTER TABLE に長い時間がかかりすぎたり、並列 DML によるテーブル変更が多すぎたりして、一時的なオンラインログのサイズが innodb_online_alter_log_max_size 構成オプションの値を超えた場合。この状態は DB_ONLINE_LOG_TOO_BIG エラーの原因になります。

  • 並列 DML が、元のテーブル定義では許可されるが、新しいテーブル定義では許可されないテーブルに変更を加えた場合。この操作は、MySQL がいちばん最後に、並列 DML ステートメントからのすべての変更を適用しようとしたときにのみ失敗します。たとえば、一意のインデックスの作成中にカラムに重複した値を挿入したり、そのカラムでの主キーのインデックスの作成中にカラムに NULL 値を挿入したりすることがあります。並列 DML によって行われた変更が優先され、ALTER TABLE 操作は実質的にロールバックされます。

構成オプション innodb_file_per_tableInnoDB テーブルの表現に大きな影響を与えますが、そのオプションが有効または無効のどちらになっているかや、テーブルが物理的に独自の .ibd ファイル内またはシステムテーブルスペースの内部のどちらに配置されているかにかかわらず、すべてのオンライン DDL 操作が同様に適切に機能します。

InnoDB には、テーブル内のすべてのデータを表すクラスタ化されたインデックスと、クエリーを高速化するためのオプションのセカンダリインデックスという 2 つのタイプのインデックスがあります。クラスタ化されたインデックスにはその B ツリーノード内のデータ値が含まれているため、クラスタ化されたインデックスの追加または削除には、データのコピーおよびテーブルの新しいコピーの作成が含まれます。ただし、セカンダリインデックスには、インデックスキーと主キーの値のみが含まれます。このタイプのインデックスは、クラスタ化されたインデックス内のデータをコピーすることなく作成または削除できます。各セカンダリインデックスには主キー値のコピー (必要に応じて、クラスタ化されたインデックスにアクセスするために使用されます) が含まれているため、主キーの定義を変更すると、すべてのセカンダリインデックスも再作成されます。

セカンダリインデックスの削除は単純です。内部の InnoDB システムテーブルと MySQL データディクショナリテーブルが、このインデックスは存在しなくなったという事実を反映するように更新されるだけです。InnoDB は、このインデックスに使用されているストレージをそれが含まれていたテーブルスペースに返して、新しいインデックスまたは追加のテーブル行がこの領域を使用できるようにします。

既存のテーブルにセカンダリインデックスを追加するには、InnoDB はそのテーブルをスキャンし、メモリーバッファーや一時ファイルを使用して各行をセカンダリインデックスキーカラムの値で順番にソートします。次に、B ツリーがキー値の順序で構築されます。これは、行をインデックスにランダムな順序で挿入するより効率的です。B ツリーノードはいっぱいになると分割されるため、このようにしてインデックスを構築するとインデックスのフィルファクタが高くなり、以降のアクセスがより効率的になります。

主キーと副キーのインデックス

従来より、MySQL サーバーと InnoDB はそれぞれ、テーブルおよびインデックス構造に関する独自のメタデータを保持しています。MySQL サーバーがこれらの情報を、トランザクションメカニズムによって保護されない .frm ファイル内に格納するのに対して、InnoDB は、独自のデータディクショナリシステムテーブルスペースの一部として保持しています。DDL 操作が途中でクラッシュまたはその他の予期しないイベントによって中断された場合は、メタデータがこれらの 2 つの場所の間で整合性がない状態のままになり、起動エラーや、変更の途中であったテーブルへのアクセス不可などの問題が発生する可能性があります。InnoDB は現在、デフォルトのストレージエンジンであるため、このような問題への対処は高い優先度を持っています。これらの DDL 操作への拡張により、このような問題が発生する可能性のある期間が削減されます。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.