このトピックでは、PolarDB for MySQL のパーティションテーブルに関するよくある質問に回答します。
PolarDB for MySQL ではパーティションテーブルはサポートされていますか?
はい。PolarDB for MySQL は MySQL と完全な互換性があり、強化された特徴とパフォーマンスを提供します。詳細については、「パーティションテーブルの概要」をご参照ください。
PolarDB for MySQL 標準テーブルをパーティションテーブルに変換する方法
標準テーブルをパーティションテーブルに変換するには、次の 3 つの方法のいずれかを使用できます。
パーティションテーブルを作成します。Data Transmission Service (DTS) を使用して、同じインスタンス内の標準テーブルからパーティションテーブルへのオンラインデータ移行を実行します。データが同期されたら、テーブルの名前を変更して切り替えを完了します。
テーブルを切り替える前に、サービスを一時的に停止して、すべての増分データが同期されていることを確認してください。
たとえば、標準テーブル t1 をパーティションテーブルに変換するには、t1_partition という名前のパーティションテーブルを作成します。次に、DTS を使用して t1 から t1_partition への増分移行を実行します。テーブル名を切り替えるための文は次のとおりです。
rename table t1 to t1_bak, t1_partition to t1;alter table ... partition byなどの コピー DDL 文 を使用してテーブルを変換できます。DDL の実行中、テーブルへの書き込み操作はブロックされます。ALTER TABLE t1 PARTITION BY RANGE COLUMNS(create_time) ( PARTITION p0 VALUES LESS THAN ('2025-01-01'), PARTITION p1 VALUES LESS THAN ('2025-02-01'), PARTITION p2 VALUES LESS THAN ('2025-03-01') );標準テーブルをパーティションテーブルにすばやく変換する場合、メタデータのみが変更されます。すべての既存データは最初のパーティションに配置されます。このプロセスでは、データの検証や再配布は行われません。したがって、パーティションの境界を正しく定義してください。
コピー DDL 構文と比較して、このメソッドは WITHOUT VALIDATION オプションを追加します。
ALTER TABLE t1 PARTITION BY RANGE COLUMNS(create_time) ( PARTITION p0 VALUES LESS THAN ('2025-01-01'), PARTITION p1 VALUES LESS THAN ('2025-02-01'), PARTITION p2 VALUES LESS THAN ('2025-03-01') ) WITHOUT VALIDATION;
PolarDB for MySQL のテーブルはいくつのパーティションをサポートできますか?
テーブルは最大 8,192 個のパーティションを持つことができます。サブパーティションを定義する場合、サブパーティションの総数は 8,192 を超えることはできません。
テーブルをパーティション分割するのに適切なデータ量はどれくらいですか?
最小データ量: テーブルをパーティション分割するために必要なデータ量に下限はありません。空のテーブルをパーティション分割することもできます。ただし、小さなテーブルをパーティション分割する必要はありません。
最大データ量: PolarDB for MySQL テーブルは最大 64 TB のデータを格納できます。したがって、64 TB を超えるテーブルはパーティション分割する必要があります。
その他の考慮事項: 従来の MySQL データベースとは異なり、PolarDB for MySQL は大きなテーブルをサポートするように最適化されています。オンラインクラスターには 40 TB を超える非パーティションテーブルがあり、そのアクセスパフォーマンスは大幅に低下しません。64 TB 未満のデータ量の場合、パーティション分割は厳密には必要ありません。データの増加予測とデータ管理のニーズに基づいて、パーティションテーブルを作成するかどうかを決定できます。
データの増加
標準テーブルをパーティションテーブルに変換する場合、RANGE パーティションテーブルにすばやく変換する場合を除き、変換に必要な時間を考慮してください。通常、DTS を使用して、データを完全に読み取って再書き込みすることでオンライン変換を実行できます。これには 1 TB のデータで約 5.8 時間かかります。その後、増分データを同期します。または、DDL 操作を使用してテーブルを変換することもできますが、これにより実行中にテーブルへのオンライン書き込み操作がブロックされます。したがって、パーティションを事前に計画してください。たとえば、将来的にパーティション分割が必要になるほどの大量のデータが予想される場合は、データ量が 10 TB を超えるまで待たないでください。パーティション分割を事前に計画してください。5 TB のデータのオンライン変換には 1 日以上かかります。
データ管理の要件
主にデータ管理のためにパーティションテーブルを使用する場合、次のシナリオではデータ量を無視できます。
既存データは月単位で削除またはアーカイブされます。最新 12 か月分のデータのみがオンラインに保持されます。非パーティションテーブルを使用する場合、時間条件に基づいて大規模な DELETE トランザクションを実行して 1 か月分のデータをクリアし、次に
OPTIMIZE TABLEコマンドを実行して削除されたデータからスペースを解放する必要があります。対照的に、月単位で範囲パーティションテーブルを作成した場合、数秒でパーティションを DROP でき、データクリーンアップが非常に効率的になります。同様に、ビジネスで日、週、四半期、または年単位でデータを管理する必要がある場合も、パーティションテーブルを使用するかどうかを決定する際にデータ量を考慮する必要はありません。パーティションテーブルは、テナントごとに HASH パーティションまたは LIST DEFAULT HASH パーティションを使用する Software as a Service (SaaS) の顧客のデータ管理も簡素化します。
テーブルをパーティション分割するかどうかは、主にデータサイズによって決まります。ただし、ビジネスシナリオでは、パーティション分割は行数に基づいていることがよくあります。データ量は単一行の長さに依存し、特定のケースごとに計算する必要があります。一般的に、それぞれ 1 KB の 10 億行は 1 TB と推定されます。テーブルが 10 億行に達したときにパーティション分割を検討できます。PolarDB for MySQL には、数百億行を含む非パーティションテーブルを持つオンラインクラスターがあり、問題なく動作します。
パーティションテーブルにはいくつのパーティションが適切ですか?
パーティションの数は、8,192 を超えない限り、ビジネスシナリオとデータ量によって異なります。
パーティションテーブルの使用方法
パーティション分割は通常、ビジネスと密接に関連しています。ビジネスデータが時間に関連している場合は、範囲パーティションを使用します。ビジネスデータがリージョンまたはテナントに関連している場合は、LIST パーティション、HASH パーティション、または LIST DEFAULT HASH パーティションを使用できます。プライマリパーティションにデータが多すぎる場合は、サブパーティションを使用できます。詳細については、「パーティション分割戦略」をご参照ください。
PolarDB for MySQL データベースにはデータベースまたはテーブルのシャーディングが必要ですか?
いいえ。シャーディングの代わりにパーティションテーブルの使用を検討してください。PolarDB for MySQL は、共有ストレージ、1 つの書き込みノード、および複数の読み取りノードを使用する、コンピューティングとストレージの分離アーキテクチャを備えた集中型データベースです。単一のパーティションまたはテーブルは最大 64 TB のデータを格納できるため、初期段階でシャーディングを検討する必要はありません。
単一のテーブルにデータが多すぎる場合、PolarDB for MySQL データベースでテーブルシャーディングを使用する方法
パーティションテーブルを使用します。パーティションテーブルの詳細については、「パーティションテーブルの概要」をご参照ください。
PolarDB for MySQL データベースのテーブルをパーティション分割した後、パーティションのフラグメントは異なるノードに保存されますか、それとも同じノードに保存されますか?
パーティションテーブルは、データを独立して管理される小さなチャンクに分割します。データは同じノードに保存されます。パーティションテーブルの詳細については、「パーティションテーブルの概要」をご参照ください。
PolarDB for MySQL の単一テーブルが数億レコードに達した場合、シャーディングが必要ですか、それともパーティションテーブルを選択すべきですか?
パーティションテーブルを使用します。パーティションテーブルの詳細については、「パーティションテーブルの概要」をご参照ください。
PolarDB for MySQL データベースはテーブルのパーティション分割をサポートしていますか? PolarDB for MySQL でのパーティション分割は意味がありますか?
はい。パーティションテーブルは、データを独立して管理される小さなチャンクに分割します。これにより、大量のデータを持つテーブルが高いパフォーマンスと高可用性を維持できます。パーティションテーブルの詳細については、「パーティションテーブルの概要」をご参照ください。
単一のテーブルに 2 TB のデータがあると推定される場合、PolarDB for MySQL と PolarDB-X のどちらを選択すべきですか?
PolarDB for MySQL の単一テーブルは最大 64 TB をサポートします。2 TB のデータ量は比較的小さいため、PolarDB for MySQL をお勧めします。データ量が 1 TB を超えるため、パーティションテーブルを使用してください。
PolarDB for MySQL はパーティションテーブルのローカルインデックスをサポートしていますか? 特定のプライマリパーティションまたはサブパーティションにセカンダリインデックスを追加できますか?
はい、サポートしています。詳細については、「部分インデックス」をご参照ください。
パーティションテーブルでフルテキストインデックスはサポートされていますか?
いいえ。
パーティションテーブルで POINT や GEOMETRY などの空間データの型はサポートされていますか?
サポートされていません
パーティションテーブルでユーザー定義の一時テーブルはサポートされていますか?
サポートされていません
パーティションテーブルで外部キーはサポートされていますか?
サポートされていません
RANGE および LIST サブパーティションはサポートされていますか?
はい。詳細については、「パーティションテーブルのタイプと使用法」をご参照ください。
パーティションテーブルで列ストアインデックスはサポートされていますか?
サポート
パーティションテーブルで X-Engine はサポートされていますか?
サポート
パーティションを作成または削除するときにテーブルはロックされますか?
PolarDB for MySQL 8.0.2 はパーティションレベルのロックをサポートしています。操作対象のパーティションのみをロックします。これにより、大規模なトランザクションが DDL 操作をブロックするのを防ぎ、他のパーティションでの DML 操作に影響を与えません。詳細については、「オンラインパーティションメンテナンス」をご参照ください。
名前のないパーティションを削除する方法
RANGE-LIST または LIST パーティションの場合、まず
SHOW CREATE TABLE文を使用してテーブルスキーマを表示します。次に、ALTER TABLE ... DROP PARTITIONコマンドを使用してパーティションを削除します。HASH パーティションの場合、まず
EXPLAIN SELECT * FROM ***文を使用してパーティション名を表示します。HASH パーティションはDROP PARTITIONをサポートしていません。HASH バケットの数を調整するには、ALTER TABLE XXX PARTITION BY HASH(XXX) PARTITIONS NUM;文を使用してテーブルを再パーティション分割する必要があります。説明この操作には時間がかかる場合があります。オフピーク時に実行してください。
PolarDB for MySQL でのパーティション分割はパフォーマンスの低下を引き起こしますか?
非パーティションテーブルと比較して、パーティションテーブルで同じ量のデータをスキャンすると、パーティション間の切り替えによりパフォーマンスのオーバーヘッドが発生します。同じデータ量の場合、非パーティションテーブルには B+ ツリーが 1 つしかありませんが、パーティションテーブルには各パーティションに B+ ツリーがあります。ツリーの深さが比較的に低いため、挿入パフォーマンスが向上します。パーティションプルーニングのために `where` 句を使用するクエリの場合、パーティションテーブルはデータスキャンと計算を削減することでパフォーマンスを向上させることができます。データベースとテーブルのシャーディングと比較して、パーティションテーブルは JOIN および DDL 操作でもパフォーマンス上の利点があります。
PolarDB for MySQL のパーティションテーブル機能には別途料金がかかりますか?
パーティションテーブル機能はカーネルの組み込み機能であり、無料です。
パーティションテーブルを使用する際に調整が必要なパラメーターはありますか?
パーティションレベルのメタデータロック (MDL) を有効にします。詳細については、「オンラインパーティションメンテナンス」をご参照ください。
DTS を使用してソースデータベースの非パーティションテーブルからターゲットデータベースのパーティションテーブルにデータを移行できますか?
はい。データ同期タスクで、ターゲットデータベースにパーティションテーブルスキーマを手動で作成します。次に、マッピング関係を構成してデータを同期します。
メジャーバージョンのアップグレード中に標準テーブルをパーティションテーブルに変換できますか?
はい。次のステップを実行します。
まず、
create table t1 (a int)のように、プライマリキーのないヘルパーテーブルをソースデータベースに追加します。これにより、メジャーバージョンのアップグレード中に事前チェックが失敗した場合にタスクが中断されることが保証されます。メジャーバージョンのアップグレードタスクを開始し、事前チェックが失敗するのを待ちます。
ターゲットデータベースにパーティションテーブルを作成します。これを行うには、Quota Center に移動します。PolarDB for MySQL [メジャーバージョンアップグレード] クォータの行で、[操作] 列の [適用] をクリックします。
t1などのヘルパーテーブルを削除します。事前チェックをスキップせずにアップグレードを続行をクリックします。DTS の事前チェックは、ターゲットデータベースに同じ名前のテーブルが存在するというエラーを再度報告します。DTS コンソールで、エラーを無視して事前チェックを再開します。事前チェックが成功すると、同期タスクが開始されます。
パーティションテーブルのデータストレージフォーマットが標準テーブルのそれと同一である限り、後続の同期タスクは正常に完了します。
パーティションテーブルを設定した後、すべてのパーティションに関する情報を表示する方法
パーティション情報をクエリするには、information_schema.PARTITIONS テーブルをクエリします。
テーブルは整数列でのみパーティション分割できますか?
KEY、RANGE COLUMN、および LIST COLUMN 構文を使用して、非整数データの列をパーティション分割できます。詳細については、「KEY」、「RANGE」、および「LIST」をご参照ください。パーティション分割関数を使用して、データ列を整数列に変換して HASH、RANGE、または LIST パーティションを使用することもできます。
パーティションテーブルの制限は何ですか?
パーティションの最大数は 8,192 を超えることはできません。
単一のパーティションは最大 64 TB のデータを格納できます。
外部キーはサポートされていません。
フルテキストインデックスはサポートされていません。
パーティションテーブルの作成方法
テーブルを作成するときに PARTITION BY 構文を使用します。さまざまなタイプのパーティションテーブルの作成方法については、「パーティションテーブルのタイプと使用法」をご参照ください。
パーティションキーを指定する方法
part_expr を使用してパーティションキーを指定します。詳細については、「パーティションテーブルのタイプと使用法」をご参照ください。
PolarDB for MySQL のパーティション分割サポートは PolarDB for PostgreSQL と同じですか?
PolarDB for PostgreSQL では、パーティションテーブルのパーティションは子テーブルであり、各パーティションは独立したテーブルです。PolarDB for MySQL では、パーティションは InnoDB テーブルです。サーバーレイヤーの観点からは、各パーティションは独立したテーブルではありません。
PolarDB for MySQL でデータテーブルをパーティション分割すると、パフォーマンスが大幅に向上しますか?
パーティションキーのフィルター条件に基づくパーティションプルーニングを使用するクエリの場合、クエリのパフォーマンスが大幅に向上します。さらに、PolarDB for MySQL はパーティションテーブルのパフォーマンスを最適化しています。詳細については、「パーティションテーブルの概要」をご参照ください。
PolarDB は、たとえば 1 日あたり 1,000 万行の新しい行を受け取り、月あたり合計 3 億行になるような大量のデータをどのように処理しますか?
詳細については、「INTERVAL RANGE」および「パーティションの自動管理」をご参照ください。オンラインパーティションメンテナンス機能を有効にすると、パーティションを自動的に追加または削除しても、他のパーティションでの DML 操作がブロックされなくなります。
パーティションテーブルでトランザクションはサポートされていますか?
これはサポートされています。
パーティションテーブルを使用する場合、データベースとテーブルのシャーディングのための分散トランザクションは必要ですか?
いいえ。
パーティション分割は書き込みパフォーマンスを向上させますか? 異なるパーティションへのデータ書き込みは互いにブロックしますか?
大量のデータの場合、書き込みパフォーマンスを向上させることができます。異なるパーティションへのデータ書き込みは互いにブロックしません。
パーティションを追加するとロックタイムアウトが発生しますか?
この状況を回避するには、オンラインパーティションメンテナンス機能を使用できます。
パーティションをドロップすると、テーブル全体のビジネス運用がブロックされるのはなぜですか?
ネイティブの MySQL では、パーティションをドロップするとテーブル全体に MDL が取得され、すべての書き込みアクセスがブロックされます。PolarDB for MySQL はパーティションレベルの MDL をサポートしています。したがって、ドロップされるパーティションでの DML 操作のみをブロックし、他のパーティションでの DML 操作はブロックしません。これにより、ビジネスへの影響が最小限に抑えられます。
パーティション分割はクエリと読み取り/書き込みのパフォーマンスに影響しますか?
SQL 文でパーティションキーを指定して、パフォーマンスへの影響を軽減します。
OPTIMIZE TABLE はパーティションテーブルでどのように機能しますか?
OPTIMIZE TABLE は、パーティションテーブル全体に MDL を取得し、すべてのパーティションでの DML 操作をブロックします。REBUILD PARTITION コマンドを オンラインパーティションメンテナンス機能と組み合わせて使用します。これにより、再構築中のパーティションでの DML 操作のみがブロックされ、他のパーティションではブロックされません。これにより、ビジネスへの影響が最小限に抑えられます。
パーティションテーブルからデータを安全に削除する方法
同じ定義で新しい空の一時テーブルを作成します。次に、データを削除するパーティションに対して EXCHANGE PARTITION 操作を実行します。最後に、一時テーブルを削除します。
パーティションテーブルのクエリプランが不正確なのはなぜですか?
パーティションテーブルの不正確なクエリプランは、主に不正確な統計が原因です。この問題は、パーティションレベルの統計の最適化によりバージョン 8.0.2 で解決されています。カーネルをバージョン 8.0.2 にアップグレードしてください。
パーティション分割中にパーティションが不均等に分散された場合はどうすればよいですか?
標準テーブルからパーティションテーブルへの変換を再度実行しますが、WITHOUT VALIDATION キーワードは追加しないでください。パーティション分割操作を再実行すると、システムは自動的にデータを再検証し、パーティションを調整します。
大量のデータがある場合、データの再検証とパーティションの設定には時間がかかることがあります。この操作はオフピーク時に実行してください。
PolarDB for MySQL で物理テーブルをパーティション分割する方法?
一般的に、各パーティションは InnoDB テーブルです。ハイブリッドパーティションは他のストレージエンジンに配置できます。
誤ってパーティションを削除した場合、そのパーティションからデータを復元できますか?
現在、データベースレベルとテーブルレベルのデータ復元のみがサポートされています。パーティションレベルのデータ復元はサポートされていません。
パーティションが多すぎることによるメモリ枯渇を解決する方法
この問題は、パーティションのメモリが共有されているため、PolarDB for MySQL バージョン 8.0.1 および 8.0.2 には存在しません。カーネルのバージョンをアップグレードしてください。
ADD PARTITION 操作に時間がかかるのはなぜですか、またそれを回避するにはどうすればよいですか?
この操作に時間がかかるのは、パーティションテーブルで大規模なトランザクションが実行されているためです。PolarDB for MySQL バージョン 8.0.2 はパーティションレベルの MDL をサポートしており、追加されるパーティションでの DML 操作のみをブロックし、他のパーティションではブロックしません。これにより、ビジネスへの影響が最小限に抑えられます。
PolarDB はテーブルパーティションを自動的に作成できますか?
はい。詳細については、「INTERVAL RANGE の概要」および「パーティションの自動管理」をご参照ください。
自動パーティション管理機能を使用する場合、RW ノードで作成されたイベントは RO ノードでも実行されますか?
PolarDB for MySQL は共有ストレージアーキテクチャを使用しています。RW ノードで作成されたイベントは RO ノードでは実行されません。単にパラメーターを ENABLE に設定するだけです。
自動パーティション管理機能を使用する場合、クラスターでプライマリ/セカンダリフェールオーバーが発生した後、新しい RW ノードはイベントの実行を継続できますか?
HA フェールオーバー後、新しい RW ノードはイベントの実行を継続できます。
自動パーティション管理を使用する場合、event_scheduler パラメーターは RW ノードと RO ノードの両方で ON に設定する必要がありますか?
パラメーターを RO ノードで ON に設定する必要はありません。RW ノードで ON に設定するだけで十分です。
標準テーブルをパーティションテーブルに変換するには、たとえば 100 GB のデータを持つテーブルの場合、どのくらいの時間がかかりますか?
標準テーブルを RANGE パーティションテーブルにすばやく変換する機能を使用すると、変換は数秒で完了します。クイック変換機能がビジネスシナリオに適していない場合は、ALTER TABLE PARTITION BY を使用してテーブル内のすべてのデータを再書き込みできます。これには約 1〜2 時間かかります。実際の時間は、クラスターの仕様とビジネスワークロードによって異なります。
LINEAR HASH パーティションと HASH パーティションの違いは何ですか?
HASH パーティション
これは剰余ハッシュとも呼ばれます。これは最も一般的なタイプのパーティション分割であり、パーティション数に対する剰余演算に基づいてデータをパーティションにルーティングします。
LINEAR HASH パーティションは、2 のべき乗のプロパティに基づいて計算を実行するハッシュアルゴリズムです。HASH パーティションと比較して、次の利点と欠点があります。
利点: 新しいパーティションを追加する場合、以前の特定のパーティションを分割することによってのみ作成できます。パーティションを追加または削除するときに読み書きする必要があるデータの割合は非常に小さいです。
欠点: データ分布の均一性が低くなります。
データがテナント ID でパーティション分割されているシナリオで、パーティションタイプとパーティション数を選択する方法
テナント ID でパーティション分割するシナリオでは、次の 2 つのパーティションタイプのいずれかを選択できます。
HASH パーティション
これは、テナント ID がランダムに生成され、データ分布が比較的分散しているシナリオに適しています。次の 3 つのシナリオに基づいてパーティション数を設定できます。
ランダムに生成されたテナント ID の場合、単一パーティションのデータ量は通常、総データ量に基づいて計算されます。単一パーティションには 500 万から 5,000 万行のデータを含めることができます。データ分布が不均一である可能性があるため、単一パーティションのデータ量は絶対的ではありません。
テナント ID が特定のパターンに従っている場合、たとえば 100、200、または 500 のパーティションを使用してデータを分割し、データがパーティション間で不均等に分散している場合は、パーティション数に素数を使用してみてください。
10 億行のデータがある場合は、100 から 200 のパーティションを作成します。単一パーティションの平均データ量は約 500 万から 5,000 万行になります。
HASH パーティションには、HASH と KEY の 2 つのサブタイプがあります。これらは同じ原則を共有し、両方とも剰余ハッシュアルゴリズムを使用します。
パーティションキー (テナント ID) が数値型の場合は、HASH パーティションを選択します。
パーティションキー (テナント ID) が文字型の場合は、KEY パーティションを選択します。
LIST DEFAULT HASH パーティション
これは、データ分布が不均一で 80/20 ルールに従うロングテールビジネスシナリオに適しています。たとえば、データ量が多い大規模テナントは少数ですが、データ量が少ない中小規模テナントは多数存在します。または、新しい小規模テナントがいつでも追加される可能性があり、テーブル作成時にすべてを列挙することはできません。このシナリオでは、1 つのパーティションテーブルで 2 つのパーティションタイプを使用できます。大規模テナントごとに個別の LIST パーティションを使用するか、複数の大規模テナントを 1 つの LIST パーティションに結合します。パーティションの数は、大規模テナントの数とそのデータ量によって異なります。その他の中小規模テナントには HASH パーティションを使用します。HASH パーティションの数を決定する方法は、HASH パーティションテーブルの場合と同じです。
パーティションテーブルを使用する場合のインデックスの選択方法
PolarDB for MySQL パーティションテーブルでは、次のいずれかのタイプのインデックスを選択できます。
ビジネスシナリオに基づいて、パーティションテーブルの異なるパーティションに異なるインデックスを作成して、異なるパーティションのクエリニーズを満たすことができます。
クエリ条件にパーティションキーが含まれていない等価クエリシナリオでは、グローバルセカンダリインデックスを使用できます。
同じデータベース内のパーティションテーブルの既存パーティションから別の新しいパーティションテーブルのパーティションにデータを移行する方法
パーティションテーブル t1 に既存パーティション p0 と p1 があるとします。これらの 2 つの既存パーティションから、新しいパーティションテーブル t2 の p0 と p1 パーティションにデータを移行する必要があります。次のステップを実行します。
p0とp1パーティションを含む、t1と同じスキーマを持つ新しいパーティションテーブルt2を作成します。移行するパーティションテーブルと同じスキーマを持つ標準テーブル
tempを作成します。EXCHANGE PARTITION を実行して、
t1テーブルの既存パーティションp0からtempテーブルにデータを移行します。ALTER TABLE t1 EXCHANGE PARTITION p0 WITH TABLE temp;t1のパーティションp0のデータ範囲がt2のパーティションp0のデータ範囲とまったく同じである場合は、データ移行 SQL 文で WITHOUT VALIDATION オプションを使用して移行を高速化できます。例:ALTER TABLE t1 EXCHANGE PARTITION p0 WITH TABLE temp WITHOUT VALIDATION;ALTER TABLE EXCHANGE PARTITION 文を実行して、
tempテーブルからt2テーブルのp0パーティションにデータを移行します。ALTER TABLE t2 EXCHANGE PARTITION p0 WITH TABLE temp;または、次の SQL 文を使用します。
ALTER TABLE t2 EXCHANGE PARTITION p0 WITH TABLE temp WITHOUT VALIDATION;移行が完了すると、テーブル
t1の既存パーティションp0のデータが、新しいパーティションテーブルt2のパーティションp0に移行されます。ステップ 3 と ステップ 4 の方法を使用して、テーブル
t1の既存パーティションp1からテーブルt2のパーティションp1にデータを移行します。すべての移行が完了したら、
tempテーブルを削除します。テーブル
t1の他のパーティションをt2に移行する必要がある場合は、テーブルt2で ADD PARTITION を使用して新しい空のパーティションを追加し、上記の手順に従ってデータを移行できます。
パーティションテーブルまたは標準テーブルで列を追加または変更する INSTANT 操作を実行した後に EXCHANGE PARTITION 操作を実行するとエラーが発生した場合はどうすればよいですか?
パーティションテーブルまたは標準テーブルで列を追加または変更する INSTANT 操作を実行した後に EXCHANGE PARTITION 操作を実行すると、次のエラーメッセージが報告されます。
ERROR 1731 (HY000): Non matching attribute 'INSTANT COLUMN(s)' between partition and table解決策: 交換を実行する前に、標準テーブルまたはパーティションテーブルを再書き込みして INSTANT 情報を削除します。再書き込みコマンドは次のとおりです。
InnoDB エンジンの標準テーブルまたはパーティションテーブルの場合、再書き込みコマンドは次のとおりです。
ALTER TABLE table_name ENGINE=InnoDB;X-Engine エンジンの標準テーブルまたはパーティションテーブルの場合、再書き込みコマンドは次のとおりです。
ALTER TABLE table_name ENGINE=xengine;
再書き込み操作はオンライン DDL であり、DML 操作やクエリには影響しませんが、リソースを消費します。テーブルに大量のデータがある場合は、オフピーク時に再書き込み操作を実行してください。次の SQL 文を使用して、再書き込み DDL の実行の進行状況と推定残り時間をクエリできます。
SELECT
pl.ID,
pl.INFO,
esc.THREAD_ID,
esc.EVENT_NAME,
(esc.WORK_COMPLETED / esc.WORK_ESTIMATED) * 100 as PROGRESS,
pl.TIME / 60 AS `EXECUTED TIME(min)`,
ROUND(
(
esc.WORK_ESTIMATED * pl.TIME / esc.WORK_COMPLETED - pl.TIME
) / 60,
2
) AS `ESTIMATED REMAINING TIME(min)`
FROM
performance_schema.events_stages_current esc
LEFT JOIN performance_schema.threads th ON esc.thread_id = th.thread_id
LEFT JOIN information_schema.PROCESSLIST pl ON th.PROCESSLIST_ID = pl.ID;パーティション名を指定してパーティションテーブルからデータをクエリする方法
PolarDB for MySQL では、パーティション名を指定してデータをクエリする構文は次のとおりです。
構文:
PARTITION (partition_names)この構文では、partition_names は 1 つ以上のパーティション名のリストを表し、次のフォーマットになります。
partition_name, partition_name, ...例:
特定のパーティションからデータをクエリする
テーブル
t1のパーティションp0からデータをクエリするには、次の文を使用できます。SELECT * FROM t1 PARTITION (p0);
複数のパーティションからデータをクエリする
複数のパーティションから同時にデータをクエリするには、パーティション名をカンマで区切ります。
SELECT * FROM t1 PARTITION (p0, p1, p2);
パーティションクエリを実行する場合、指定したパーティション名が実際のテーブルスキーマのパーティション名と完全に同じであることを確認する必要があります。
パーティションクエリ構文は、パーティションテーブルをサポートするテーブルタイプに適用でき、データベースバージョンは対応する機能をサポートしている必要があります。