すべてのプロダクト
Search
ドキュメントセンター

PolarDB:手順

最終更新日:Sep 01, 2026

「クイックスタート」セクションを参照してハイブリッドトランザクション/分析処理 (HTAP) ワークロード用にクラスターを設定するか、「高度な使用方法」セクションを参照して特定のビジネス要件に合わせて IMCI をカスタマイズしてください。

クイックスタート

ステップ1:読み取り専用 IMCI ノードの追加

PolarDB コンソールにログインします。ナビゲーションペインで、 [クラスターリスト] をクリックします。クラスターの リージョン を選択し、対象のクラスターを見つけます。操作 列で、 ノードの追加/削除 をクリックして、読み取り専用 IMCI ノードを追加します。

説明
  • クラスターの購入時にすでに読み取り専用 IMCI ノードを追加している場合は、この手順をスキップしてください。

  • ご使用のクラスターは、IMCI のバージョン要件を満たしている必要があります。詳細については、「読み取り専用 IMCI ノード」をご参照ください。

ステップ2:リクエストルーティングの設定

ビジネス要件に応じて、自動または手動のリクエストルーティングを選択して IMCI を使用できます。

  • 自動リクエストルーティング:オンライン トランザクション処理 (OLTP) とオンライン分析処理 (OLAP) のワークロードが同じアプリケーションからデータベースにアクセスする場合、スキャンされた行数によって決まる推定実行コストに基づいて、読み取りリクエストを読み取り専用 IMCI ノードまたは読み取り専用行ストアノードに自動的にルーティングできます。

  • 手動リクエストルーティング:OLTP と OLAP のワークロードが異なるアプリケーションからデータベースにアクセスする場合、これらのアプリケーション用に異なるクラスターエンドポイントを設定できます。その後、異なるエンドポイントのサービスノードに読み取り専用 IMCI ノードと読み取り専用行ストアノードを割り当て、リクエストを行ストアと列ストアにルーティングできます。

自動リクエストルーティング

クラスター詳細ページで、 データベースへの接続 セクションに移動します。クラスターのエンドポイント の [行ストア/列ストア自動ルーティング] を 有効 に設定します。

説明

手動リクエストルーティング

クラスター詳細ページで、 データベースへの接続 セクションに移動し、カスタムエンドポイントを作成します。サービスノード には [読み取り専用 IMCI ノード] のみを含めるようにしてください。

ステップ3:IMCI の追加

ビジネス要件に応じて、手動または自動でテーブルに IMCI を追加できます。

重要

クエリを IMCI で高速化するには、SQL ステートメントで参照されるすべての列が IMCI で完全にカバーされている必要があります。

手動

IMCI は、ビジネステーブルに IMCI を追加または削除するための一連の DDL ステートメントを提供します。ニーズに合ったオプションを選択してください:

DDL 構文

例

テーブル作成時の IMCI の作成

-- 特定の列に IMCI を追加します。
CREATE TABLE <table_name>(
  <column_name_1> INT COMMENT 'COLUMNAR=1',
  <column_name_2> VARCHAR(100)
) ENGINE InnoDB;

-- テーブル全体に IMCI を追加します。
CREATE TABLE <table_name>(
  <column_name_1> INT,
  <column_name_2> VARCHAR(100)
) ENGINE InnoDB COMMENT 'COLUMNAR=1';

IMCI の動的な追加または削除

-- 特定の列に IMCI を追加します。
ALTER TABLE <table_name> MODIFY COLUMN <column_name_1> INT COMMENT 'COLUMNAR=1';
               
-- テーブル全体に IMCI を追加します。
ALTER TABLE <table_name> COMMENT 'COLUMNAR=1';

データベースまたはテーブルレベルでの IMCI の一括追加または削除

-- テーブル全体に IMCI を追加します。
CREATE COLUMNAR INDEX ON <db_name>.<table_name>;

-- データベース内のすべてのテーブルに IMCI を追加します。
CREATE COLUMNAR INDEX FOR TABLES IN <db_name>;
説明
  • IMCI を追加する際、既存のコメントを保持できます。例: ALTER TABLE <table_name> COMMENT 'COLUMNAR=1 <元のコメント>';

  • デフォルトでは、データベースまたはテーブルレベルで IMCI を一括追加すると、テーブルコメントは 'COLUMNAR=1 <元のコメント>' に更新されます。

自動

AutoIndex 機能は、スロークエリに基づいて自動的に IMCI を作成し、その実行速度を大幅に向上させることができます。これにより、各スロークエリを理解して調整する必要がなくなります。アプリケーションのワークロードが変化すると、AutoIndex は IMCI 戦略を継続的に監視および調整し、PolarDB クラスターが最適なパフォーマンスを維持できるようにします。

PolarDB クラスター詳細ページで AutoIndex を 有効 にするだけで、この機能のメリットを享受できます:

[設定] セクションで [AutoIndex] (デフォルトでは [無効]) を見つけ、その右側にある 有効 をクリックします。

(任意) ステップ4:IMCI ビルド進捗の確認

手動で IMCI を追加した後、そのビルド進捗を確認してください。クエリの高速化の恩恵を受けるには、ビルドが完了するまで待機してください。

SELECT * FROM INFORMATION_SCHEMA.IMCI_ASYNC_DDL_STATS;

例: IMCI が完全に構築されたことを確認するには、STATUS 列の値が Safe to read であることを確認します。

+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
| SCHEMA_NAME | TABLE_NAME | CREATED_AT          | STARTED_AT          | FINISHED_AT         | STATUS       | APPROXIMATE_ROWS | SCANNED_ROWS    | SCAN_SECOND | SORT_ROUNDS | SORT_SECOND | BUILD_ROWS | BUILD_SECOND | AVG_SPEED | SPEED_LAST_SECOND | ESTIMATE_SECOND |
+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
| tpch        | lineitem   | 2024-10-21 13:44:02 | 2024-10-21 13:44:02 | 2024-10-21 13:50:11 | Safe to read | 590446240        | 600037902(100%) | 369         | 0           | 0           | 0(0%)      | 0            | 1625058   | 0                 | 0               |
+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
1 row in set, 1 warning (0.00 sec)

(任意) ステップ5:IMCI 使用状況の確認

IMCI の実行計画は水平ツリーとして表示され、行ストアの実行計画とは明らかに異なる形式です。EXPLAIN ステートメントを使用して実行計画を表示し、SQL ステートメントが IMCI で高速化できるかどうかを判断できます。以下の例でその違いを示します:

IMCI 実行計画

+----+----------------------------+----------+--------+--------+-----------------------------------------------------------------------------+
| ID | Operator                   | Name     | E-Rows | E-Cost | Extra Info                                                                  |
+----+----------------------------+----------+--------+--------+-----------------------------------------------------------------------------+
|  1 | Select Statement           |          |        |        | IMCI Execution Plan (max_dop = 4, max_query_mem = 858993459)                |
|  2 | └─Sort                     |          |        |        | Sort Key: revenue DESC,o_orderdate ASC                                      |
|  3 |   └─Hash Groupby           |          |        |        | Group Key: (lineitem.L_ORDERKEY, orders.O_ORDERDATE, orders.O_SHIPPRIORITY) |
|  4 |     └─Hash Join            |          |        |        | Join Cond: orders.O_ORDERKEY = lineitem.L_ORDERKEY                          |
|  5 |       ├─Hash Join          |          |        |        | Join Cond: customer.C_CUSTKEY = orders.O_CUSTKEY                            |
|  6 |       │ ├─Table Scan       | customer |        |        | Cond: (C_MKTSEGMENT = "BUILDING")                                           |
|  7 |       │ └─Table Scan       | orders   |        |        | Cond: (O_ORDERDATE < 03/24/1995)                                            |
|  8 |       └─Table Scan         | lineitem |        |        | Cond: (L_SHIPDATE > 03/24/1995)                                             |
+----+----------------------------+----------+--------+--------+-----------------------------------------------------------------------------+
8 rows in set (0.01 sec)

行ストア実行計画

+----+-------------+----------+------------+------+--------------------+------------+---------+-----------------------------+--------+----------+----------------------------------------------+
| id | select_type | table    | partitions | type | possible_keys      | key        | key_len | ref                         | rows   | filtered | Extra                                        |
+----+-------------+----------+------------+------+--------------------+------------+---------+-----------------------------+--------+----------+----------------------------------------------+
|  1 | SIMPLE      | customer | NULL       | ALL  | PRIMARY            | NULL       | NULL    | NULL                        | 147630 |    10.00 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | orders   | NULL       | ref  | PRIMARY,ORDERS_FK1 | ORDERS_FK1 | 4       | tpch100g.customer.C_CUSTKEY |     14 |    33.33 | Using where                                  |
|  1 | SIMPLE      | lineitem | NULL       | ref  | PRIMARY            | PRIMARY    | 4       | tpch100g.orders.O_ORDERKEY  |      4 |    33.33 | Using where                                  |
+----+-------------+----------+------------+------+--------------------+------------+---------+-----------------------------+--------+----------+----------------------------------------------+
3 rows in set, 1 warning (0.00 sec)

ヘルパーツール

IMCI を使用して複雑な SQL ステートメントをクエリする場合、SQL ステートメント内の列が IMCI でカバーされていないかどうかを確認する必要があります。カバーされていない列が見つかった場合は、その SQL ステートメント用に IMCI を作成するための DDL ステートメントを取得するか、特定のワークロード用に IMCI を作成するための DDL ステートメントを一括取得できます。DDL ステートメントを実行した後、SQL ステートメントで参照されるすべての列が IMCI でカバーされていることを確認し、クエリの高速化を有効にしてください。

PolarDB は、以下の組み込みストアドプロシージャを提供します:

よくある質問

クエリが IMCI を使用しない

読み取り専用 IMCI ノードを追加した後、SQL ステートメントでクエリされるすべてのテーブルに対して IMCI を作成する必要もあります。ステートメントが IMCI を使用するのは、その推定実行コストが特定のしきい値を超えた場合のみです。さらに、高速化するためには、SQL ステートメントが読み取り専用 IMCI ノードに転送される必要があります。SQL ステートメントが IMCI を使用していない場合は、次の手順に従って問題をトラブルシューティングしてください:

  1. SQL ステートメントが読み取り専用 IMCI ノードに転送されていることを確認します。

    • データベースエンドポイントの サービスノード に読み取り専用 IMCI ノードが含まれているかどうかを確認してください。

    • SQL Explorer を使用して、SQL ステートメントが読み取り専用 IMCI ノードに転送されていることを確認してください。

    サービスノード が有効になっている クラスターのエンドポイント を使用し、SQL ステートメントの推定実行コストが loose_imci_ap_threshold または loose_cost_threshold_for_imci のしきい値よりも高い場合、PolarProxy は SQL ステートメントを読み取り専用 IMCI ノードに転送します。また、 SELECT キーワードの前に HINT 構文 /*FORCE_IMCI_NODES*/ を追加して、SQL ステートメントを強制的に読み取り専用 IMCI ノードにルーティングすることもできます。詳細については、「自動ルーティングのしきい値の設定」をご参照ください。例:

    データベースエンジンのマイナーバージョン 8.0.1.1.39 および 8.0.2.2.23 以降では、loose_imci_ap_threshold パラメーターは非推奨となり、loose_cost_threshold_for_imci パラメーターに置き換えられました。
    /*FORCE_IMCI_NODES*/EXPLAIN SELECT COUNT(*) FROM t1 WHERE t1.a > 1;
    新しいデータベースエンドポイントを作成すると、SQL ステートメントが常に実行のために読み取り専用 IMCI ノードにルーティングされるようになります。詳細については、「新しいデータベースエンドポイントの作成」をご参照ください。
  2. SQL ステートメントの推定実行コストが設定されたしきい値を超えているかどうかを確認してください。

    読み取り専用 IMCI ノードでは、オプティマイザが SQL ステートメントの実行コストを推定します。推定実行コストが loose_imci_ap_threshold または loose_cost_threshold_for_imci で設定されたしきい値を超えると、オプティマイザは IMCI を使用します。そうでない場合は、既存の行ベースのインデックスを使用します。

    SQL ステートメントが読み取り専用 IMCI ノードに転送されることを確認した後、 EXPLAIN を使用して表示した実行計画がまだ IMCI を使用していない場合、推定実行コストをプリセットのしきい値と比較して、推定実行コストが低すぎたために IMCI が使用されなかったかどうかを判断できます。Last_query_cost_for_imci 変数をクエリして、前の SQL ステートメントの推定実行コストを取得できます:

    -- EXPLAIN を使用して SQL ステートメントの実行計画を表示します。
    EXPLAIN SELECT * FROM t1;
    -- 前のクエリの推定実行コストを取得します。
    SHOW STATUS LIKE 'Last_query_cost_for_imci';
    クラスターエンドポイントを使用してデータベースに接続する場合、 SHOW STATUS LIKE 'Last_query_cost_for_imci' の前に HINT 構文 /*ROUTE_TO_LAST_USED*/ を追加することを推奨します。これにより、正しいノードで前のステートメントの推定実行コストをクエリできます。例: /*ROUTE_TO_LAST_USED*/SHOW STATUS LIKE 'Last_query_cost_for_imci';

    SQL ステートメントの推定実行コストが設定されたしきい値より低い場合は、 loose_imci_ap_threshold または loose_cost_threshold_for_imci の値を調整することを検討してください。たとえば、 HINT を使用して単一の SQL ステートメントのしきい値を調整できます:

    /*FORCE_IMCI_NODES*/EXPLAIN SELECT /*+ SET_VAR(cost_threshold_for_imci=0) */ COUNT(*) FROM t1 WHERE t1.a > 1;
  3. SQL ステートメント内のすべてのテーブルと列が IMCI で完全にカバーされていることを確認してください。

    組み込みストアドプロシージャ dbms_imci.check_columnar_index('<query_string>') を呼び出して、SQL ステートメント内のテーブルまたは列に対して IMCI が作成されているかどうかを確認できます。詳細については、「SQL ステートメント内のテーブルまたは列に対して IMCI が作成されているかどうかの確認」をご参照ください。例:

    CALL dbms_imci.check_columnar_index('SELECT COUNT(*) FROM t1 WHERE t1.a > 1');

    SQL ステートメントが IMCI で完全にカバーされていない場合、このストアドプロシージャを呼び出すと、カバーされていないテーブルと列が返されます。返された各テーブルと列に対して IMCI を作成する必要があります。ステートメントが完全にカバーされている場合、プロシージャは空の結果セットを返します。

  4. サポートされていない SQL 機能がないか確認してください。

    IMCI の構文使用制限を確認し、特定の SQL 機能が IMCI をサポートしているかどうかを確認してください。詳細については、「IMCI 構文使用制限」をご参照ください。

上記の手順を実行しても SQL ステートメントが IMCI を使用しない場合は、使用ガイドを参照するか、お問い合わせください。

詳細については、「IMCI FAQ」をご参照ください。

高度な使用方法

IMCI の使用を最適化するには、次のトピックをご参照ください。

高度な機能

説明

IMCI のソートキーの設定

IMCI はデータを複数の行グループに編成します。各行グループでは、異なる列が列データブロックにパックされます。これらのブロックは、元の行ベースデータの主キー順に基づいて並列で構築されるため、全体として順序付けられていない状態になります。ソートキーを設定して列データブロックを並べ替え、クエリのパフォーマンスを向上させることができます。

JSON データの効率的な分析

IMCI は、列指向 JSON、仮想列、Instant DDL、列数拡張などの一連の機能を統合して、大規模な構造化および半構造化データ分析を処理します。

IMCI による ETL の高速化

抽出、変換、ロード (ETL) 機能により、読み書き (RW) ノードで IMCI を使用できます。RW ノードで発行された SELECT リクエストは、クエリを高速化するために読み取り専用 IMCI ノードに送信されます。データが読み取られた後、システムは内部ネットワーク経由で RW ノードにデータを転送し、宛先テーブルに書き込みます。

読み取り専用 IMCI ノードのサーバーレスの有効化

サーバーレス 機能は、ワークロードに基づいてリソースを自動的にスケールアップおよびスケールダウンします。ピーク時にはスケールアップしてワークロードの急増に対応し、オフピーク時にはスケールダウンしてコストを削減します。

ハイブリッドプランによるワイドテーブルクエリの高速化

ハイブリッドプランは、同じクエリで列インデックスと行インデックスの両方を使用します。ハイブリッドプランは、ワイドテーブルのクエリパフォーマンスを大幅に向上させることができます。実行計画では、列インデックスの恩恵を受ける部分は IMCI 上で実行され、主キーのみを含む中間結果が生成されます。次に、必要な列が InnoDB の主キーインデックスを使用して主キーでフェッチされ、返されます。

マルチノード MPP による大規模データ分析の高速化

大規模データに対する複雑なクエリでは、単一の読み取り専用 IMCI ノードではパフォーマンス要件を満たせない場合があります。マルチノード並列処理 (MPP) を使用してクエリを高速化できます。

詳細情報

IMCI の背後にある原理についてさらに学ぶには、次のドキュメントをご参照ください: