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

PolarDB:手順

最終更新日:Jul 02, 2026

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

クイックスタート

手順1:読み取り専用 IMCI ノードの追加

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

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

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

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

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

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

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

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

クラスター詳細ページで、データベースへの接続 セクションに移動します。クラスターのエンドポイント で、サービスノード有効 に設定します。image

説明

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

「クラスター詳細」ページで、データベースへの接続 セクションに移動し、カスタムエンドポイントを作成します。サービスノード には、サービスノード のみを含めるようにします。image

手順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 を 有効 するだけで、この機能のメリットを体験できます:

image

(オプション) 手順4:IMCI のビルド進捗の確認

IMCI を手動で追加した後、ビルドの進捗状況を確認します。クエリを高速化するには、ビルドが完了するのを待ちます。

SELECT * FROM INFORMATION_SCHEMA.IMCI_ASYNC_DDL_STATS;

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

+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
| 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 エクスプローラーを使用して、SQL ステートメントが読み取り専用 IMCI ノードに転送されているか確認します。

    サービスノード が有効になっている クラスターのエンドポイント を使用し、SQL ステートメントの 推定実行コストloose_imci_ap_threshold または loose_cost_threshold_for_imci のしきい値よりも高い場合、PolarProxy は SQL ステートメントを読み取り専用 IMCI ノードに転送します。また、/*FORCE_IMCI_NODES*/ という ヒント 構文を SELECT キーワードの前に追加して、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';
    クラスターエンドポイントを使用してデータベースに接続する場合、ヒント構文 /*ROUTE_TO_LAST_USED*/SHOW STATUS LIKE 'Last_query_cost_for_imci' の前に追加することを推奨します。これにより、正しいノードで前のステートメントの 推定実行コスト を照会できます。例: /*ROUTE_TO_LAST_USED*/SHOW STATUS LIKE 'Last_query_cost_for_imci';

    SQL ステートメントの 推定実行コスト が設定されたしきい値より低い場合は、loose_imci_ap_threshold または loose_cost_threshold_for_imci の値を調整することを検討してください。たとえば、ヒントを使用して、単一の 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仮想列インスタント DDL列数拡張などの一連の機能を統合し、大規模な構造化および半構造化データ分析を処理します。

IMCI を使用した ETL の高速化

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

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

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

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

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

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

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

詳細情報

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