PolarDB:パーティションテーブルに関するFAQ

PolarDB for MySQL ではパーティションテーブルはサポートされていますか？

はい、PolarDB for MySQL ではパーティションテーブルがサポートされています。PolarDB for MySQL は MySQL と完全な互換性があり、強化された機能とパフォーマンスを提供します。詳細については、「概要」をご参照ください。

PolarDB for MySQL テーブルはいくつのパーティションをサポートしていますか？

PolarDB for MySQL は最大 8,192 個のパーティションをサポートしています。サブパーティションが定義されている場合は、最大 8,192 個のサブパーティションがサポートされます。

テーブルをパーティション分割するのに適切なデータ量はどれくらいですか？

• 最小データ量: テーブルのパーティション分割に必要なデータ量に下限はありません。空のテーブルでもパーティション分割できます。ただし、小さなテーブルをパーティション分割してもパフォーマンスはあまり向上しません。

• 最大データ量: PolarDB for MySQL テーブルには最大 64 TB のデータを格納できます。したがって、64 TB を超えるサイズのテーブルにはパーティション分割が必要です。

• その他: 従来の MySQL データベースとは異なり、PolarDB for MySQL は大きなテーブルの処理に優れています。クラスタに 40 TB を超えるサイズのパーティション化されていないテーブルが含まれていても、クラスタのアクセス パフォーマンスは大幅に低下しません。64 TB 未満のデータを含むテーブルでは、パーティション分割は不要です。データの増加とデータ管理のプリファレンスに基づいて、パーティションテーブルを作成するかどうかを決定できます。

  • データの増加

    テーブルをパーティション分割する場合、範囲パーティションテーブル以外のテーブルをパーティションテーブルに変換するために必要な時間を考慮してください。ほとんどの場合、Data Transmission Service (DTS) を使用してデータ全体を読み取って書き換え、パーティション化されていないテーブルをパーティションテーブルに変換し、増分データを同期できます。1 TB のデータの読み取りと書き換えには約 5.8 時間かかります。また、DDL 操作を実行して、パーティション化されていないテーブルをパーティションテーブルに変換することもできます。ただし、DDL 操作の実行中は、テーブルに対する読み取り操作がブロックされます。したがって、変換前にパーティション分割を事前に計画する必要があります。大量のデータがパーティション化されていないテーブルに書き込まれ、将来テーブルをパーティション化する必要があると想定される場合は、10 TB などの大量のデータがテーブルに書き込まれるまでテーブルのパーティション化を待つのではなく、テーブルのパーティション化を事前に計画することをお勧めします。これは、大量のデータを含むテーブルのパーティション化には長い時間がかかる可能性があるためです。たとえば、5 TB のデータを含むテーブルをパーティション化するには 1 日以上かかる場合があります。

  • データ管理要件

    データ管理を容易にするためにテーブルをパーティション分割する場合、次のシナリオではテーブル内のデータ量は考慮事項ではない場合があります。

    • 履歴データは月ごとに削除またはアーカイブされます。 過去 12 か月間のデータのみがオンラインで保持されます。 large テーブルを使用してデータを格納する場合、time の範囲でテーブルから 1 か月分のデータをクリアするために large な DELETE トランザクションを実行し、OPTIMIZE TABLE 構文を使用してクリアされたデータの領域を解放する必要があります。 月ごとにデータを格納するために範囲パーティションテーブルを作成する場合、数秒でパーティションを削除することで 1 か月分のデータをクリアできます。 この方法では、データは効率的にクリアされます。 テーブルが日、週、四半期、年単位のデータ管理に使用される場合、テーブルをパーティション化するかどうかを判断する際に、テーブル内のデータ量を考慮する必要もありません。

    • Software as a Service (SaaS) のお客様は、テナントに基づいて HASH または LIST DEFAULT HASH メソッドを使用してテーブルをパーティション分割します。この場合、パーティションテーブルは、お客様がデータをより効率的に管理するのに役立ちます。

テーブル内のデータサイズに基づいて、テーブルをパーティション化するかどうかを決定できます。ただし、パーティション分割は、実際のビジネスシナリオではテーブル内の行数に基づいて実行されます。行数は、1 行のサイズによって異なります。ほとんどの場合、それぞれ 1,000 バイトを含む 10 億行は 1 TB のサイズと推定されます。パーティション化されていないテーブルに 10 億行以上含まれている場合は、テーブルをパーティション化することをお勧めします。実際には、PolarDB for MySQL クラスタ内の数十億行を含むパーティション化されていないテーブルも、パフォーマンスの問題なくビジネス要件を満たすことができます。

パーティションテーブルにはいくつのパーティションが適切ですか？

パーティションの数は、最大 8,192 個のパーティションを作成できるという条件で、ビジネスシナリオとデータ量に基づいて決定されます。

パーティション分割ポリシーはどのように選択しますか？

パーティション分割ポリシーはビジネスデータに関連しています。ビジネスデータが時間関連の場合は、RANGE パーティション分割を使用することをお勧めします。ビジネスデータが地域またはテナントに関連している場合は、LIST パーティション分割、HASH パーティション分割、または LIST DEFAULT HASH パーティション分割を使用できます。LIST DEFAULT HASH パーティション分割ポリシーの詳細については、「LIST DEFAULT HASH」をご参照ください。パーティションに過剰な量のデータがある場合は、サブパーティションを使用できます。詳細については、「パーティション分割ポリシーを選択する」をご参照ください。

信頼性の向上:PolarDB for MySQL データベースではシャーディングは必要ですか？

いいえ、PolarDB for MySQL データベースではシャーディングは必要ありません。シャーディングの代わりに、パーティションテーブルを使用できます。PolarDB for MySQL は、共有ストレージを使用し、1 つのプライマリノードと複数の読み取り専用ノードを含む、コンピューティングとストレージが分離されたデータベースです。単一のパーティションまたはテーブルには、最大 64 TB のデータを格納できます。この場合、シャーディングは必要ありません。

パーティション化されていない PolarDB for MySQL テーブルに過剰な量のデータが含まれている場合、シャーディングはどのように使用しますか？

パーティションテーブルを使用することをお勧めします。パーティションテーブルの詳細については、「概要」をご参照ください。

PolarDB for MySQL データベースのパーティションテーブルのパーティションは、1 つのノードに格納されますか、それとも複数のノードに格納されますか？

パーティションテーブルはデータを小さなパーティションに分割します。各パーティションは、データを独立して編成および管理します。パーティションのデータは 1 つのノードに格納されます。パーティションテーブルの詳細については、「概要」をご参照ください。

1 億行を超えるデータを含むパーティション化されていないテーブルがある場合、シャーディングは必要ですか？ それともパーティション分割が推奨されますか？

パーティションテーブルを使用することをお勧めします。パーティションテーブルの詳細については、「概要」をご参照ください。

パーティション分割は 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 などの特殊なデータ型はサポートされていますか？

いいえ、パーティションテーブルでは、POINT や GEOMETRY などの特殊なデータ型はサポートされていません。

パーティションテーブルでは一時テーブルはサポートされていますか？

いいえ、パーティションテーブルでは一時テーブルはサポートされていません。

パーティションテーブルでは外部キーはサポートされていますか？

いいえ、パーティションテーブルでは外部キーはサポートされていません。

RANGE または LIST サブパーティション分割はサポートされていますか？

はい、RANGE または LIST サブパーティション分割はサポートされています。詳細については、「概要」をご参照ください。

パーティションテーブルではインメモリ列インデックス (IMCI) はサポートされていますか？

はい、パーティションテーブルでは IMCI がサポートされています。

X-Engine Edition クラスタにパーティションテーブルを作成できますか？

はい、X-Engine Edition クラスタにパーティションテーブルを作成できます。

パーティションを作成および削除するときに、パーティションテーブルはロックされますか？

PolarDB for MySQL 8.0.2 では、パーティションレベルの MDL がサポートされています。この場合、現在のパーティションのみがロックされます。これにより、大きなトランザクションが DDL 操作をブロックしたり、他のパーティションの DML 操作に影響を与えたりするのを防ぎます。詳細については、「オンラインパーティションメンテナンス」をご参照ください。

名前がわからない場合、パーティションを削除するにはどうすればよいですか？

• range-list パーティションまたは list パーティションの場合は、SHOW CREATE TABLE 文を実行してその名前を取得し、ALTER TABLE ... DROP PARTITION 文を実行して削除します。

• Hash パーティションには明示的な名前がありません。テーブルの作成時に指定されたハッシュ関数とバケット (パーティション) の数に基づいて、データベースシステムによって自動的に管理されます。ハッシュパーティション全体でのデータ分布を表示するには、EXPLAIN SELECT * FROM *** 文を実行します。パーティションの数を変更するには、ALTER TABLE XXX PARTITION BY HASH(XXX) PARTITIONS NUM; 文を実行します。

  説明

  パーティションの削除には時間がかかります。この操作はオフピーク時に実行することをお勧めします。

パーティションが追加されたときにパフォーマンスは低下しますかPolarDB for MySQL にパーティションを追加すると、パフォーマンスが低下しますか？

パーティション化されていないテーブルと比較して、パーティションテーブル内の同じ量のデータをスキャンするには、パーティション間を切り替える必要があります。この場合、パフォーマンスが低下します。同じ量のデータの場合、パーティション化されていないテーブルには B+ ツリーが 1 つだけあります。ただし、パーティションテーブルでは、各パーティションに 1 つの B+ ツリーがあり、階層レイヤーが少なくなっています。パーティションテーブルに対する INSERT 操作は、より高いパフォーマンスを提供します。WHERE 条件をパーティションプルーニングに追加して、スキャンと計算に関係するデータ量を削減できるため、パーティションテーブルではクエリのパフォーマンスが向上します。シャーディングと比較して、パーティションテーブルは JOIN 操作と DDL 操作でより高いパフォーマンスを提供します。

パーティションテーブルに追加料金は発生しますか？PolarDB for MySQL のパーティションテーブルに追加料金は発生しますか？

いいえ、パーティションテーブルはカーネルの組み込み機能であるため、追加料金は発生しません。

パーティションテーブルを使用する場合、パラメータ設定を変更する必要がありますか？

パーティションレベルの MDL 機能を有効にすることをお勧めします。詳細については、「オンラインパーティションメンテナンス」をご参照ください。

DTS を使用して、ソースデータベースのパーティション化されていないテーブルからターゲットデータベースのパーティションテーブルにデータを移行できますか？

はい、DTS を使用して、ソースデータベースのパーティション化されていないテーブルからターゲットデータベースのパーティションテーブルにデータを移行できます。データ同期タスクで、パーティションテーブルの構造を手動で作成し、データ同期のマッピングを構成します。

メジャーバージョンアップグレード中に、パーティション化されていないテーブルをパーティションテーブルに変換できますか？

はい、メジャーバージョンアップグレード中に、パーティション化されていないテーブルをパーティションテーブルに変換できます。メジャーバージョンアップグレード中にパーティション化されていないテーブルをパーティションテーブルに変換するには、次の操作を実行します。

1. ソースデータベースに主キーのないテーブルを作成します。たとえば、create table t1 (a int) 文を実行してテーブルを作成できます。これにより、メジャーバージョンアップグレード中に失敗した事前チェックタスクが中断されます。

2. 事前チェックが失敗するまで、メジャーバージョンアップグレードタスクを開始します。

3. ターゲットデータベースにパーティションテーブルを作成します。次の手順を実行します。クォータセンター に移動します。[適用]アクションPolarDB for MySQL メジャーバージョンアップグレード に対応する 列の をクリックします。

4. 以前に作成した t1 などのテーブルを削除します。「アップグレードを続行」をクリックします。事前チェックをスキップしないでください。事前チェック中に、ターゲットデータベースに同じ名前のテーブルが再びあることを示すエラーが DTS によって報告されます。

5. DTS コンソールでエラーをブロックし、事前チェックを再起動します。事前チェックが成功すると、タスクはデータ同期を開始します。

6. パーティションテーブルのデータ形式がパーティション化されていないテーブルのデータ形式と同じである場合、データ同期は成功します。

パーティションの情報をクエリするにはどうすればよいですか？

information_schema.PARTITIONS テーブルでパーティションの情報をクエリできます。

パーティションテーブルでは整数データ型の列のみをパーティション分割できますか？

整数データ型ではない列をキー、範囲、またはリスト列パーティションとして設定できます。詳細については、「KEY」、「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 は、パーティションテーブルのパフォーマンス最適化も提供します。詳細については、「概要」をご参照ください。

1 つのテーブルに 1 日あたり 1,000 万行の新しいデータがある場合、1 か月で 3 億行の新しいデータが追加されます。PolarDB for MySQL は、過剰な量のデータをどのように処理しますか?

詳細については、「INTERVAL RANGE」および「パーティションの自動管理」をご参照ください。さらに、オンラインパーティションメンテナンス機能を有効にすることで、テーブルへのパーティションの自動追加または削除時に、他のパーティションでの DML 操作がロックされるのを回避できます。この機能の詳細については、「オンラインパーティションメンテナンス」をご参照ください。

パーティションテーブルでトランザクションはサポートされていますか?

はい。パーティションテーブルではトランザクションがサポートされています。

パーティションテーブルを使用する場合、分散トランザクションをシャーディングする必要がありますか?

いいえ、パーティションテーブルを使用する場合、分散トランザクションをシャーディングする必要はありません。

パーティションの書き込みパフォーマンスを向上させることはできますか? 1 つのパーティションへのデータ書き込みは、別のパーティションへのデータ書き込みをブロックしますか?

大量のデータの場合、書き込みパフォーマンスを向上させることができます。異なるパーティションへのデータ書き込みは、互いに影響を与えません。

パーティションを追加するとロックのタイムアウトが発生しますか?

この問題を防ぐために、オンラインパーティションメンテナンス機能を使用できます。詳細については、「オンラインパーティションメンテナンス」をご参照ください。

DROP PARTITION 操作がテーブルのトランザクションをブロックするのはなぜですか?

ネイティブ MySQL では、DROP PARTITION 操作はテーブルの MDL を取得します。そのため、テーブルへのすべての書き込みがロックされます。PolarDB for MySQL はパーティションレベルの MDL をサポートしています。この場合、現在のパーティションに対する DML 操作のみがロックされ、他のパーティションに対する DML 操作はロックされません。これにより、ビジネスへの影響が最小限に抑えられます。

パーティション分割はクエリと読み取り/書き込みのパフォーマンスに影響しますか?

はい、パーティション分割はクエリと読み取り/書き込みのパフォーマンスに影響します。パフォーマンスの低下を軽減するために、SQL 文でパーティションキーを指定することをお勧めします。

前提条件

OPTIMIZE TABLE操作では、テーブルにMDLを追加して、すべてのパーティションでDML操作をロックします。 ビジネスへの影響を最小限に抑えるために、オンラインパーティションメンテナンス機能とともにREBUILD PARTITIONコマンドを使用することを推奨します。 この方法では、現在のパーティションでのDML操作のみがロックされ、他のパーティションでのDML操作はブロックされません。 コマンドの詳細については、「再構築パーティー」をご参照ください。 機能の詳細については、「パーティションの再構築オンラインパーティションメンテナンス」をご参照ください。

パーティションテーブルのデータを安全に削除するにはどうすればよいですか?

次の手順を実行します。同じ定義を使用する空の一時テーブルを作成し、データを削除するパーティションで [EXCHANGE PARTITION] 文を実行してから、一時テーブルを削除します。

パーティションテーブルのクエリプランが不正確なのはなぜですか?

パーティションテーブルのクエリプランが不正確になる主な原因は、統計情報が不正確であることです。PolarDB for MySQL 8.0.2 では、パーティションレベルの統計情報が最適化され、この問題が解決されています。クラスターを PolarDB for MySQL 8.0.2 にアップグレードすることをお勧めします。

テーブルに毎日 1,000 万行の新しいデータがあり、1 か月に 3 億行の新しいデータが追加される場合、PolarDB for MySQL は過剰な量のデータをどのように処理しますか？

パーティション化されていないテーブルをパーティションテーブルに変換する を、WITHOUT VALIDATION キーワードを指定せずに再度実行します。システムは自動的にデータを検証し、パーティションを調整します。

物理テーブルをパーティション分割するにはどうすればよいですか？PolarDB for MySQL

ほとんどの場合、各パーティションは InnoDB テーブルです。ハイブリッドパーティションは、他のエンジンに格納できます。

パーティションのデータを誤って削除した場合、復元できますか?

いいえ、パーティションのデータを誤って削除した場合、復元することはできません。データベースまたはテーブルのデータのみを復元できます。

作成されたパーティションの数が多いことによってメモリが枯渇した場合はどうすればよいですか？

この問題は、PolarDB for MySQL 8.0.1 または 8.0.2 では存在しません。パーティション間でメモリが共有されるためです。クラスターのマイナーバージョンを更新することをお勧めします。

ADD PARTITION 操作の完了に時間がかかる場合はどうすればよいですか?

ADD PARTITION 操作の完了に時間がかかるのは、現在のパーティションで大きなトランザクションが進行中であるためです。PolarDB for MySQL 8.0.2 は、パーティションレベルの MDL をサポートしています。これは、現在のパーティションの DML 操作のみをロックし、他のパーティションの DML 操作はロックしません。これにより、ビジネスへの影響が最小限に抑えられます。

PolarDB for MySQL でパーティションは自動的に作成されますか?

はい。PolarDB for MySQL ではパーティションを自動的に作成できます。詳細については、「INTERVAL RANGE」および「パーティションの自動管理」をご参照ください。

パーティションテーブルではトランザクションはサポートされていますか？

PolarDB for MySQL は共有ストレージを使用します。プライマリノードで作成されたイベントは、読み取り専用ノードでは実行されません。イベントのプロパティを 有効 に設定できます。

パーティションテーブルを使用する場合、分散トランザクションをシャード化する必要がありますか？

いいえ、パーティションテーブルを使用する場合、分散トランザクションをシャード化する必要はありません。

パーティションの書き込みパフォーマンスを向上させることはできますか？ 1 つのパーティションへのデータ書き込みは、別のパーティションへのデータ書き込みをブロックしますか？

大量のデータの場合、書き込みパフォーマンスを向上させることができます。異なるパーティションへのデータ書き込みは互いに影響しません。

パーティションを追加するとロックタイムアウトが発生しますか？

パーティション化されていないテーブルを範囲パーティションテーブルに変換する場合、変換プロセスは数秒で完了します。そうでない場合は、ALTER TABLE PARTITION BY 文を実行して、パーティション化されていないテーブルのすべてのデータを範囲パーティションテーブルに再書き込みできます。このプロセスは、完了するまでに約 1 ～ 2 時間かかります。実際の所要時間は、クラスタの仕様と負荷によって異なります。詳細については、「パーティション化されていないテーブルを範囲パーティションテーブルに変換する」をご参照ください。

LINEAR HASH パーティショニングと HASH パーティショニングの違いは何ですか?

• ハッシュパーティション

  ハッシュパーティション分割は、モジュロハッシュとも呼ばれ、パーティション番号のモジュラスに基づいてパーティションをルーティングするために使用される最も一般的なパーティション分割メソッドです。

• LINEAR HASH パーティショニング

  LINEAR HASH パーティショニングは、2 次のべき乗の特性に基づいて計算されるハッシュアルゴリズムです。HASH パーティショニングと比較して、LINEAR HASH パーティショニングには次の長所と短所があります。

  • 長所: パーティションが作成されるとき、各パーティションは、以前に決定されたパーティションからのみ分割できます。パーティションの作成および削除中に読み書きする必要があるデータの割合はわずかです。

  • 短所: マッピングの均一性は弱いです。

パーティション分割はクエリと読み取り/書き込みのパフォーマンスに影響しますか？

テナントIDによるパーティショニングには、次のパーティショニング方法を使用できます。

• ハッシュパーティション

  テナント ID がランダムに生成され、データ分布が分散しているシナリオに適しています。パーティションの数は、次のシナリオに基づいて決定できます。

  • ランダムに生成されたテナント ID の場合、単一パーティションのデータ量は総データ量に基づいて計算されます。ほとんどの場合、データ量は 500 万～ 5,000 万です。ただし、データは必ずしも均等に分散されているとは限りません。したがって、単一パーティションのデータ量は絶対的なものではない場合があります。

  • テナント ID が特定のパターン（100、200、500 パーティションに分割されるなど）に従い、各パーティション内でデータが均等に分散されていない場合は、素数をパーティション番号として使用できます。

  • データ量が 10 億の場合、100 ～ 200 のパーティションを作成することをお勧めします。単一パーティションの平均データ量は約 500 万～ 5,000 万です。

  ハッシュパーティションには、HASH と KEY の 2 つのサブタイプがあります。どちらのタイプもモジュロハッシュアルゴリズムを使用します。

  • パーティションキーのテナント ID が数値型の場合は、HASH パーティションを選択します。

  • パーティションキーのテナント ID が文字型の場合は、KEY パーティションを選択します。

• リストデフォルトハッシュパーティション

  データ分布が不均一で、パレートの法則に従うロングテールシナリオに適しています。たとえば、少数の大きなテナントは大量のデータを持っている可能性がありますが、多数の中小規模のテナントはデータが少ない可能性があります。または、小さなテナントがいつでも追加される可能性があり、テーブルの作成時に列挙できません。このシナリオでは、同じパーティションテーブルで LIST パーティションと HASH パーティションを使用できます。大きなテナントは個別に LIST パーティションを使用することも、複数の大きなテナントを 1 つの LIST パーティションに結合することもできます。パーティションの数は、大きなテナントの数とデータ量によって異なります。その他の中小規模のテナントは HASH パーティションを使用でき、パーティションの数は HASH パーティションテーブルと同じ方法で決定されます。

OPTIMIZE TABLE 操作はパーティションテーブルでどのように機能しますか？

PolarDB for MySQL のパーティションテーブルを使用する場合、テーブルに対して次のいずれかの種類のインデックスを選択できます。

• 部分インデックス

  実際のビジネスシナリオに基づいて、パーティションテーブルの異なるパーティションに異なるインデックスを作成し、クエリ要件を満たすことができます。

• GSI

  クエリ条件にパーティションキーが含まれていないが、等価クエリが必要なシナリオでは、グローバルセカンダリインデックス (GSI) を使用できます。

パーティションテーブルのデータをエクスポートするにはどうすればよいですか？

t1 という名前のパーティションテーブルには、p0 と p1 という 2 つの履歴パーティションがあります。t2 という名前の新しいパーティションテーブルの p0 パーティションと p1 パーティションに、2 つの履歴パーティションのデータを移行します。この場合、次の操作を実行します。

1. 新しいパーティションテーブル t2 を作成します。これは、t1 テーブルと同じ構造を使用し、p0 パーティションと p1 パーティションを含みます。

2. パーティション化されていないテーブル temp を作成します。これは、t1 テーブルと同じ構造を使用します。

3. ALTER TABLE 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;

4. 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;

   これにより、p0t1p0t2 テーブルの履歴パーティション のデータが テーブルの パーティションに移行されます。

5. 手順 3 と 手順 4 の操作を実行して、t1 テーブルの履歴パーティション p1 から t2 テーブルの p1 パーティションにデータを移行します。

6. 必要なデータがすべて移行された後、temp テーブルを削除します。

   t1 テーブルの他のパーティションのデータを t2 テーブルに移行する必要がある場合は、ALTER TABLE ADD PARTITION 文を実行して t2 テーブルに新しい空のパーティションを追加し、上記の手順を実行してデータを移行できます。

パーティションテーブルまたは非パーティションテーブルで INSTANT 文を実行した後に EXCHANGE PARTITION 文を実行すると、エラーメッセージが返される場合はどうすればよいですか。

パーティションテーブルまたは非パーティションテーブルの列を追加または変更するために INSTANT 文を実行した後に EXCHANGE PARTITION 文を実行すると、次のエラーメッセージが返されます。

ERROR 1731 (HY000): Non matching attribute 'INSTANT COLUMN(s)' between partition and table

解決策: EXCHANGE PARTITION 文を実行する前に、次の文を実行して、非パーティションテーブルまたはパーティションテーブルを再書き込みし、INSTANT 情報を削除します。

• InnoDB エンジンを使用するクラスタの非パーティションテーブルまたはパーティションテーブルに対して、次の文を実行します。

  ALTER TABLE table_name ENGINE=InnoDB;

• X-Engine エンジンを使用するクラスタの非パーティションテーブルまたはパーティションテーブルに対して、次の文を実行します。

  ALTER TABLE table_name ENGINE=xengine;

上記の文はオンライン DDL 文です。 DML 操作とクエリ操作には影響しませんが、リソースを消費します。 テーブルに大量のデータが格納されている場合は、オフピーク時にテーブルを再書き込みする必要があります。 次の SQL 文を実行して、再書き込みの進捗状況と推定残り時間をクエリできます。

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 は、パーティション名またはパーティション名のリストです。次のフォーマットを使用します。

partition_name, partition_name, ...

例:

• 指定されたパーティションのデータをクエリします。

  • 次の文を実行して、テーブル t1 のパーティション p0 のデータをクエリします。

    SELECT * FROM t1 PARTITION (p0);

• 複数のパーティションのデータをクエリします。

  • クエリ文では、複数のパーティションをカンマ (,) で区切ります。

    SELECT * FROM t1 PARTITION (p0, p1, p2);