PolarDB:DDL操作

PolarDB for MySQL 8.0.2

PolarDB for MySQL 8.0.1

PolarDB for MySQLの5.7

PolarDB for MySQLの5.6

PolarDB for MySQL 8.0.2

PolarDB for MySQL 8.0.1

PolarDB for MySQLの5.7

PolarDB for MySQLの5.6

PolarDB for MySQL 8.0.2

1. インスタントADD COLUMN機能を使用すると、テーブルの最後にのみ列を追加できます。 テーブルにプライマリキーが指定されていない場合は、必ずimplicit_primery_keyパラメーターをOFFに設定してください。 これにより、テーブルの末尾に暗黙の主キー列があるため、列の追加に失敗するのを防ぎます。 インスタントADD COLUMN機能は、圧縮テーブル (ROW_FORMAT=compressed) 、フルテキストインデックスを持つテーブル、または一時テーブルではサポートされません。 クラスターがインスタントADD COLUMN機能をサポートしていない場合、システムはINPLACEアルゴリズムを使用して列を追加します。 これにより、テーブルの再構築がトリガーされます。 テーブルの再構築プロセス中、同時の読み取りおよび書き込み操作が許可されます。 並列DDL機能を使用して、列の追加を高速化できます。

   インメモリ列インデックス (IMCI) を含むテーブルに列を追加すると、IMCIが再構築されます。 したがって、IMCIを含むテーブルでは、インスタントADD列機能はサポートされません。 この問題を解決するには、loose_imci_enable_add_column_instant_ddlパラメーターをONに設定して、インスタントADD COLUMN機能を有効にします。 このようにして、IMCIはPolarDBによってバックグラウンドで非同期的に再構築され、一時的に利用できなくなります。 詳細については、「DDLステートメントを実行してIMCIを動的に作成および削除する」をご参照ください。

2. VARCHAR列の長さを即座に増やすには、VARCHAR列の値を格納するために使用されるバイト数が同じであることを確認します。 サイズが0〜255バイトの範囲内のVARCHAR列には、1バイトのストレージが必要です。 サイズが256バイト以上のVARCHAR列には、2バイトのストレージが必要です。 VARCHAR列の長さを同じ範囲 (0〜255バイトまたは256バイト以上) 内で制御した場合のみ、ストレージ要件は変わりません。 これらのシナリオでは、ALTER TABLEステートメントの実行時にメタデータのみが更新されます。 長さが255バイトのしきい値を超えると、PolarDBは自動的にCOPYアルゴリズムを使用します。 このプロセスには、読み取りのみが許可されるテーブルロックが含まれます。

   変更されたVARCHAR列の長さが同じバイトサイズの範囲内にあるかどうかわからない場合は、DDL操作にALGORITHM=INPLACE句を使用します。 インスタント列拡張がサポートされていない場合、エラーが返されます。 例：

   ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);
   
   ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

   VARCHAR値によって消費されるスペースは、実際の長さによって異なります。 そのため、VARCHAR列の最大長を256バイト以上に設定して、列長拡張のテーブルコピー (ALGORITHM=copy) を回避することを推奨します。

3. 次の条件を満たす場合、列の文字セットがUTF8mb3からUTF8mb4に変更され、メタデータのみが変更されます。 条件が満たされない場合、COPYアルゴリズムが使用される。 これにより、テーブルのロックと再構築が行われ、その間は読み取り操作のみが許可されます。

   • 列タイプは、CHAR、VARCHAR、ENUM、またはTEXTです。

   • 変更する列にインデックスが存在しません。

   • 列の最大長は、255バイトまで、または255バイト以上のいずれかで一貫しています。

   ALGORITHM=INPLACEを指定すると、テーブルの再構築を必要とせずにDDLを強制的に実行できます。 DDL操作がCOPYアルゴリズムを使用してのみ実行できる場合、エラーが返されます。 例：

   ALTER TABLE test modify column b char(1) CHARACTER SET utf8mb4 default null,algorithm = inplace;
   ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

4. ENUM列またはSET列の定義を変更すると、データ型のストレージサイズが変更されず、リストの最後にメンバーが追加されるという条件が満たされた場合にのみ、メタデータが変更されます。 それ以外の場合は、テーブルコピーが必要です。

PolarDB for MySQL 8.0.1

1. インスタントADD COLUMN機能を使用すると、テーブルの最後に列を追加できます。 テーブルにプライマリキーが指定されていない場合は、必ずimplicit_primery_keyパラメーターをOFFに設定してください。 これにより、テーブルの末尾に暗黙の主キー列があるため、列の追加に失敗するのを防ぎます。 インスタントADD COLUMN機能は、圧縮テーブル (ROW_FORMAT=compressed) 、フルテキストインデックスを持つテーブル、または一時テーブルではサポートされません。 クラスターがインスタントADD COLUMN機能をサポートしていない場合、システムはINPLACEアルゴリズムを使用して列を追加します。 これにより、テーブルの再構築がトリガーされます。 テーブルの再構築プロセス中、同時の読み取りおよび書き込み操作が許可されます。 並列DDL機能を使用して、列の追加を高速化できます。

   インメモリ列インデックス (IMCI) を含むテーブルに列を追加すると、IMCIが再構築されます。 したがって、IMCIを含むテーブルでは、インスタントADD列機能はサポートされません。 解決策は、loose_imci_enable_add_column_instant_ddlをONに設定することで、インスタントCOLUMN機能を有効にすることです。 このようにして、IMCIはPolarDBによってバックグラウンドで非同期的に再構築され、一時的に利用できなくなります。 詳細については、「DDLステートメントを実行してIMCIを動的に作成および削除する」をご参照ください。

2. VARCHAR列の長さを即座に増やすには、VARCHAR列の値を格納するために使用されるバイト数が同じであることを確認します。 サイズが0〜255バイトの範囲内のVARCHAR列には、1バイトのストレージが必要です。 サイズが256バイト以上のVARCHAR列には、2バイトのストレージが必要です。 VARCHAR列の長さを同じ範囲 (0〜255バイトまたは256バイト以上) 内で制御した場合のみ、ストレージ要件は変わりません。 これらのシナリオでは、ALTER TABLEステートメントの実行時にメタデータのみが更新されます。 長さが255バイトのしきい値を超えると、PolarDBは自動的にCOPYアルゴリズムを使用します。 このプロセスにはテーブルロックが含まれ、その間は読み取り操作のみが許可されます。

   変更されたVARCHAR列の長さが同じバイトサイズの範囲内にあるかどうかわからない場合は、DDL操作にALGORITHM=INPLACE句を使用します。 インスタント列拡張がサポートされていない場合、エラーが返されます。 例：

   ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);
   
   エラー0A000: ALGORITHM=INPLACEはサポートされていません。 理由: 列タイプINPLACEを変更できません。 ALGORITHM=COPYを試してください。

   VARCHAR値によって消費されるスペースは、実際の長さによって異なります。 そのため、VARCHAR列の最大長を256バイト以上に設定して、列長拡張のテーブルコピー (ALGORITHM=copy) を回避することを推奨します。

3. loose_innodb_support_instant_modify_charsetがONに設定されていて、次の条件が満たされている場合、メタデータのみを変更して、列の文字セットをUTF8mb3からUTF8mb4に変更できます。 条件が満たされない場合、COPYアルゴリズムが使用される。 これにより、テーブルのロックと再構築が行われ、その間は読み取り操作のみが許可されます。

   • 列タイプは、CHAR、VARCHAR、ENUM、またはTEXTです。

   • 変更する列にインデックスが存在しません。

   • 列の最大長は、255バイトまで、または255バイト以上のいずれかで一貫しています。

   ALGORITHM=INPLACEを指定すると、テーブルの再構築を必要とせずにDDLを強制的に実行できます。 DDL操作がCOPYアルゴリズムを使用してのみ実行できる場合、エラーが返されます。 例：

   ALTER TABLEテストは列b charを変更します (1) CHARACTER SET utf8mb4デフォルトnull、algorithm = inplace;
   エラー1846 (0A000): ALGORITHM=INPLACEはサポートされていません。 理由: 列タイプINPLACEを変更できません。 ALGORITHM=COPYを試してください。

4. ENUM列またはSET列の定義を変更すると、データ型のストレージサイズが変更されず、リストの最後にメンバーが追加された場合にのみ、メタデータが変更されます。 それ以外の場合は、テーブルコピーが必要です。

PolarDB for MySQLの5.7

1. インスタントADD COLUMN機能を有効にするには、loose_innodb_support_instant_add_columnをONに設定します。 この機能を使用すると、テーブルの最後にのみ列を追加できます。 テーブルにプライマリキーが指定されていない場合は、必ずimplicit_primery_keyパラメーターをOFFに設定してください。 これにより、テーブルの末尾に暗黙の主キー列があるため、列の追加に失敗するのを防ぎます。 インスタントADD COLUMN機能は、圧縮テーブル (ROW_FORMAT=compressed) 、フルテキストインデックスを持つテーブル、または一時テーブルではサポートされません。 クラスターがインスタントADD COLUMN機能をサポートしていない場合、システムはINPLACEアルゴリズムを使用して列を追加します。 これにより、テーブルの再構築がトリガーされます。 テーブルの再構築プロセス中、同時の読み取りおよび書き込み操作が許可されます。 並列DDL機能を使用して、列の追加を高速化できます。

2. VARCHAR列の長さを即座に増やすには、VARCHAR列の値を格納するために使用されるバイト数が同じであることを確認します。 サイズが0〜255バイトの範囲内のVARCHAR列には、1バイトのストレージが必要です。 サイズが256バイト以上のVARCHAR列には、2バイトのストレージが必要です。 VARCHAR列の長さを同じ範囲 (0〜255バイトまたは256バイト以上) 内で制御した場合のみ、ストレージ要件は変わりません。 これらのシナリオでは、ALTER TABLEステートメントの実行時にメタデータのみが更新されます。 長さが255バイトのしきい値を超えると、PolarDBは自動的にCOPYアルゴリズムを使用します。 このプロセスにはテーブルロックが含まれ、その間は読み取り操作のみが許可されます。

   変更されたVARCHAR列の長さが同じバイトサイズの範囲内にあるかどうかわからない場合は、DDL操作にALGORITHM=INPLACE句を使用します。 インスタント列拡張がサポートされていない場合、エラーが返されます。 例：

   ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256);
   
   エラー0A000: ALGORITHM=INPLACEはサポートされていません。 理由: 列タイプINPLACEを変更できません。 ALGORITHM=COPYを試してください。

   VARCHAR値によって消費されるスペースは、実際の長さによって異なります。 そのため、VARCHAR列の最大長を256バイト以上に設定して、列長拡張のテーブルコピー (ALGORITHM=copy) を回避することを推奨します。

3. ENUM列またはSET列の定義を変更すると、データ型のストレージサイズが変更されず、リストの最後にメンバーが追加された場合にのみ、メタデータが変更されます。 それ以外の場合は、テーブルコピーが必要です。

PolarDB for MySQLの5.6

1. インスタントADD COLUMN機能を有効にするには、loose_innodb_support_instant_add_列パラメーターをONに設定します。 この機能を使用すると、テーブルの最後にのみ列を追加できます。 テーブルにプライマリキーが指定されていない場合は、必ずimplicit_primery_keyパラメーターをOFFに設定してください。 これにより、テーブルの末尾に暗黙の主キー列があるため、列の追加に失敗するのを防ぎます。 インスタントADD COLUMN機能は、圧縮テーブル (ROW_FORMAT=compressed) 、フルテキストインデックスを持つテーブル、一時テーブル、またはパーティションテーブルではサポートされません。 クラスターがインスタントADD COLUMN機能をサポートしていない場合、システムはINPLACEアルゴリズムを使用して列を追加します。 これにより、テーブルの再構築がトリガーされます。 テーブルの再構築プロセス中、同時の読み取りおよび書き込み操作が許可されます。

   説明

   PolarDB For MySQL 5.6の場合、インスタントADD COLUMN機能はカナリアリリースにあります。 この機能を使用するには、クォータセンターに移動し、クォータID polardb_mysql_iac_56に対応するクォータ名を見つけ、[適用] をクリックします。

2. ENUM列またはSET列の定義を変更すると、データ型のストレージサイズが変更されず、リストの最後にメンバーが追加された場合にのみ、メタデータが変更されます。 それ以外の場合は、テーブルコピーが必要です。

PolarDB for MySQL 8.0.2

PolarDB for MySQL 8.0.1

PolarDB for MySQLの5.7

PolarDB for MySQLの5.6

PolarDB for MySQL 8.0.2

PolarDB for MySQL 8.0.1

PolarDB for MySQLの5.7

PolarDB for MySQLの5.6

PolarDB for MySQL 5.6は、生成された列操作をサポートしていません。

PolarDB for MySQL 8.0.2

PolarDB for MySQL 8.0.1

PolarDB for MySQLの5.7

PolarDB for MySQLの5.6

PolarDB for MySQL 8.0.2

1. パーティションのメタデータロック (MDL) を有効にするためにloose_partition_level_mdl_enabledパラメーターをtrueに設定した後、DDL操作は無関係なパーティションのDML操作に影響を与えません。 詳細については、「オンラインパーティションのメンテナンス」をご参照ください。

2. ADD PARTITIONまたはDROP PARTITIONをRANGEまたはLISTパーティションで使用しても、テーブルを再構築する必要はありません。 ADD PARTITIONまたはDROP PARTITIONをHASHまたはKEYパーティションで使用するには、テーブルの再構築が必要です。 DROP PARTITIONは、HASHまたはKEYパーティションでは使用できません。

3. COALESCE PARTITIONは、HASHおよびKEYパーティションでのみ使用できます。

4. InnoDBテーブルでOPTIMIZE PARTITIONを実行すると、パーティションテーブル全体の再構築がトリガーされます。 テーブルの再構築中は、読み取りおよび書き込み操作が許可されます。 パラレルDDLを使用してテーブルの再構築を高速化するには、innodb_parallel_build_primary_indexパラメーターをONに設定します。 詳細については、「パラレルDDL」をご参照ください。

5. 通常のテーブルは、レンジパーティションテーブルにのみ即座に変換できます。 詳細については、「共通テーブルを範囲パーティションテーブルに切り替える」をご参照ください。

6. PolarDB for MySQLを使用すると、特定のパーティションのインデックスを作成および削除できます。 詳細は、「部分インデックス」をご参照ください。

7. REORGANIZE PARTITIONおよびREBUILD PARTITIONは、指定されたパーティションのみに影響します。

8. ANALYZE PARTITIONは、テーブルのメタデータとデータではなく、統計のみを変更します。

9. CHECK PARTITIONは、テーブルのメタデータとデータを変更しません。

10. REPAIR PARTITIONは指定されたパーティションのみを再構築します。

PolarDB for MySQL 8.0.1

1. ADD PARTITIONまたはDROP PARTITIONをRANGEまたはLISTパーティションで使用しても、テーブルを再構築する必要はありません。 HASHおよびKEYパーティションでADD PARTITIONを使用するには、テーブルの再構築が必要です。

2. DROP PARTITIONは、HASHまたはKEYパーティションでは使用できません。

3. InnoDBテーブルでOPTIMIZE PARTITIONを実行すると、パーティションテーブル全体の再構築がトリガーされます。 テーブルの再構築中は、読み取りおよび書き込み操作が許可されます。 パラレルDDLを使用してテーブルの再構築を高速化するには、innodb_parallel_build_primary_indexパラメーターをONに設定します。 詳細については、「パラレルDDL」をご参照ください。

4. REORGANIZE PARTITION、REBUILD PARTITION、およびREPAIR PARTITIONは、指定されたパーティションのみに影響します。

5. ANALYZE PARTITIONは、テーブルのメタデータとデータではなく、統計のみを変更します。

6. CHECK PARTITIONは、テーブルのメタデータとデータを変更しません。

PolarDB for MySQLの5.7

1. ADD PARTITIONまたはDROP PARTITIONをRANGEまたはLISTパーティションで使用しても、テーブルを再構築する必要はありません。 ADD PARTITIONまたはDROP PARTITIONをHASHまたはKEYパーティションで使用するには、テーブルの再構築が必要です。 DROP PARTITIONは、HASHまたはKEYパーティションでは使用できません。

2. REORGANIZE PARTITION、REBUILD PARTITION、およびREPAIR PARTITIONは、指定されたパーティションのみに影響します。

3. ANALYZE PARTITIONは、テーブルのメタデータとデータではなく、統計のみを変更します。

4. CHECK PARTITIONは、テーブルのメタデータとデータを変更しません。

PolarDB for MySQLの5.6

1. ADD PARTITIONまたはDROP PARTITIONをRANGEまたはLISTパーティションで使用しても、テーブルを再構築する必要はありません。 ADD PARTITIONまたはDROP PARTITIONをHASHまたはKEYパーティションで使用するには、テーブルの再構築が必要です。 DROP PARTITIONは、HASHまたはKEYパーティションでは使用できません。

2. REORGANIZE PARTITION、REBUILD PARTITION、およびREPAIR PARTITIONは、指定されたパーティションのみに影響します。

3. ANALYZE PARTITIONは、テーブルのメタデータとデータではなく、統計のみを変更します。

4. CHECK PARTITIONは、テーブルのメタデータとデータを変更しません。