このトピックでは、PolarDB-X でクラスタ化カラムナーインデックス (CCI) 機能を作成および使用して、データに対する分析クエリを高速化する方法について説明します。
前提条件
CCI 機能を使用するには、インスタンスが以下の要件を満たしている必要があります。
インスタンスエディション:
AUTOモードデータベースを備えた Enterprise Edition。インスタンスバージョン: 5.4.19-16989811 以上。
インスタンスバージョンの命名規則については、「リリースノート」をご参照ください。
インスタンスのバージョンを表示する方法については、「インスタンスのバージョンを表示および更新する」をご参照ください。
注意事項
CCI を作成する際には、以下の制約が適用されます。
プレフィックスインデックスは使用できません。
CCI を作成する際は、インデックス名を指定する必要があります。
デフォルトでは、CCI にはプライマリテーブルのすべての列が含まれます。 CCI が作成されると、プライマリテーブルの列の変更に基づいて自動的に調整されます。 列を手動で調整することはできません。
CCI を作成しても、追加のローカルインデックスは作成されません。
インデックス定義では、ソートキーの
LENGTHパラメーターは無視されます。
プライマリインスタンス、読み取り専用インスタンス、およびカラムストア読み取り専用インスタンスは、
SHOW INDEXなどのクエリコマンドをサポートしています。 詳細については、「SHOW COLUMNAR INDEX」、「SHOW COLUMNAR OFFSET」、および「SHOW COLUMNAR STATUS」をご参照ください。DDL 関連の制限の詳細については、「制限」をご参照ください。
構文
PolarDB-Xは、MySQL のデータ定義言語 (DDL) ステートメントの構文を拡張します。 CCI を定義するために、以下の構文が追加されています。 この構文は、MySQL でインデックスを作成するのと同じ方法で使用できます。
CREATE
CLUSTERED COLUMNAR INDEX index_name
ON tbl_name (index_sort_key_name,...)
[partition_options]
# パーティションポリシーを定義する
partition_options:
PARTITION BY
HASH({column_name | partition_func(column_name)})
| KEY(column_list)
| RANGE({column_name | partition_func(column_name)})
| RANGE COLUMNS(column_list)
| LIST({column_name | partition_func(column_name)})
| LIST COLUMNS(column_list)} }
partition_list_spec
# パーティション関数を定義する
partition_func:
YEAR
| TO_DAYS
| TO_SECOND
| UNIX_TIMESTAMP
| MONTH
# パーティションリストを定義する
partition_list_spec:
hash_partition_list
| range_partition_list
| list_partition_list
# HASH/KEY パーティションテーブルの列を定義する
hash_partition_list:
PARTITIONS partition_count
# RANGE/RANGE COLUMNS パーティションテーブルの列を定義する
range_partition_list:
range_partition [, range_partition ...]
range_partition:
PARTITION partition_name VALUES LESS THAN {(expr | value_list)} [partition_spec_options]
# LIST/LIST COLUMNS パーティションテーブルの列を定義する
list_partition_list:
list_partition [, list_partition ...]
list_partition:
PARTITION partition_name VALUES IN (value_list) [partition_spec_options]例
t_order という名前のテーブルと、t_order テーブルに cc_i_seller という名前の CCI を作成するには、次のステートメントを実行します。
CREATE TABLE t_order (
`id` bigint(11) NOT NULL AUTO_INCREMENT,
`order_id` varchar(20) DEFAULT NULL,
`buyer_id` varchar(20) DEFAULT NULL,
`seller_id` varchar(20) DEFAULT NULL,
`order_snapshot` longtext DEFAULT NULL,
`order_detail` longtext DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `l_i_order` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by hash(`order_id`) partitions 16;CREATE CLUSTERED COLUMNAR INDEX `cc_i_seller` ON t_order (`seller_id`) partition by hash(`order_id`) partitions 16;次のセクションでは、CCI 作成コードについて詳しく説明します。
CLUSTERED COLUMNAR:追加するインデックスのタイプが CCI であることを指定するキーワード。
プライマリテーブル:
t_orderは、order_id列で HASH パーティションを使用するパーティションテーブルです。インデックス名:SQL ステートメントでインデックスを指定するために使用されるインデックスの名前。
ソートキー:インデックスのソートキー。 インデックスファイルのデータは、この列に基づいて順番に格納されます。
インデックスパーティション句:インデックスのパーティションアルゴリズム。 この句の構文は、
CREATE TABLEステートメントの partition 句の構文と同じです。 この句では、order_idがハッシュ列です。インデックス定義句:
CLUSTERED COLUMNAR INDEX `cc_i_seller` ON t_order (`seller_id`) partition by hash(`order_id`) partitions 16。
クエリで CCI を使用する方法
CCI を作成した後、次の方法でクエリに使用するインデックステーブルを指定できます。
ヒントを使用してインデックスを指定する
構文:
FORCE INDEX({index_name})例:
SELECT a.*, b.order_id
FROM t_seller a
JOIN t_order b FORCE INDEX(cc_i_seller) ON a.seller_id = b.seller_id
WHERE a.seller_nick="abc";インデックス選択方法
CCI を含むプライマリテーブルに対するクエリの場合、PolarDB-X は、オプティマイザーが最もコストが低いと判断したインデックステーブルを自動的に選択します。 現在、CCI ベースのクエリはカラムストア読み取り専用インスタンスのみでサポートされています。
指定されたインデックスを使用しない(IGNORE INDEX)
構文:
IGNORE INDEX({index_name},...)次のステートメントは、オプティマイザーが cc_i_seller インデックスを使用しないことを指定します。
SELECT t_order.id,t_order.order_snapshot FROM t_order IGNORE INDEX(cc_i_seller) WHERE t_order.seller_id = 's1';指定されたインデックスを使用する(USE INDEX)
構文:
USE INDEX({index_name},...)次のステートメントは、オプティマイザーが cc_i_seller インデックスを使用することを指定します。
SELECT t_order.id,t_order.order_snapshot FROM t_order USE INDEX(cc_i_seller) WHERE t_order.seller_id = 's1';制限
制限事項は、次の 3 つのタイプに分類されます。
CCI を作成する場合、プライマリキー、ソートキー、およびパーティションキーのデータ型には一定の制限があります。
CCI を含むテーブルで DDL ステートメントを実行する場合、特定の制限が適用されます。 現在、一般的な DDL ステートメントのみがサポートされています。
DDL ステートメントを実行して列のデータ型を変更する場合、サポートされるデータ型は限られています。
サポートされているデータ型
次の表は、プライマリテーブルのプライマリキー、および CCI のソートキーとパーティションキーでサポートされているデータ型を示しています。
データ型 | プライマリキー | ソートキー | パーティションキー | |
数値型 | BIT (UNSIGNED) | サポートされています | サポートされています | サポートされていません |
TINYINT (UNSIGNED) | サポートされています | サポートされています | サポートされています | |
SMALLINT (UNSIGNED) | サポートされています | サポートされています | サポートされています | |
MEDIUMINT (UNSIGNED) | サポートされています | サポートされています | サポートされています | |
INT (UNSIGNED) | サポートされています | サポートされています | サポートされています | |
BIGINT (UNSIGNED) | サポートされています | サポートされています | サポートされています | |
時間型 | DATE | サポートされています | サポートされています | サポートされています |
DATETIME | サポートされています | サポートされています | サポートされています | |
TIMESTAMP | サポートされています | サポートされています | サポートされています | |
TIME | サポートされています | サポートされています | サポートされていません | |
YEAR | サポートされています | サポートされています | サポートされていません | |
文字列型 | CHAR | サポートされています | サポートされています | サポートされています |
VARCHAR | サポートされています | サポートされています | サポートされています | |
TEXT | サポートされています | サポートされています | サポートされていません | |
BINARY | サポートされています | サポートされています | サポートされています | |
VARBINARY | サポートされています | サポートされています | サポートされています | |
BLOB | サポートされています | サポートされています | サポートされていません | |
浮動小数点数型 | FLOAT | サポートされていません | サポートされていません | サポートされていません |
DOUBLE | サポートされていません | サポートされていません | サポートされていません | |
DECIMAL | サポートされていません | サポートされていません | サポートされていません | |
NUMERIC | サポートされていません | サポートされていません | サポートされていません | |
特殊型 | JSON | サポートされていません | サポートされていません | サポートされていません |
ENUM | サポートされていません | サポートされていません | サポートされていません | |
SET | サポートされていません | サポートされていません | サポートされていません | |
POINT | サポートされていません | サポートされていません | サポートされていません | |
GEOMETRY | サポートされていません | サポートされていません | サポートされていません | |
パーティションアルゴリズムは、さまざまなデータ型をサポートしています。 詳細については、「データ型」をご参照ください。
DDL 文の制限
次のステートメントを使用して、CCI を含むテーブルで DDL ステートメントの実行を許可するかどうかを制御できます(true:許可、false:許可しない)。
SET [GLOBAL] forbid_ddl_with_cci = [true | false];次の表は、CCI を含むプライマリテーブルと CCI に対する DDL サポートについて説明しています。
カテゴリ
アクション
SQL の例
サポートされている
プライマリテーブル
テーブルの削除
DROP TABLE tbl_name;はい
テーブルの切り捨て
TRUNCATE TABLE tbl_name;はい
テーブルの名前変更
ALTER TABLE old_tbl_name RENAME TO new_tbl_name;RENAME TABLE old_tbl_name TO new_tbl_name;
はい
複数のテーブルの名前変更
RENAME TABLE tbl_name_a to tbl_name_b, tbl_name_c to tbl_name_d;はい
列の追加
ALTER TABLE tbl_name ADD col_name TYPE;はい
列の削除
ALTER TABLE tbl_name DROP COLUMN col_name;はい
列型の変更
ALTER TABLE tbl_name MODIFY col_name TYPE;はい
列の名前変更 (変更)
ALTER TABLE tbl_name CHANGE old_col new_col TYPE;はい
列のデフォルト値の変更
ALTER TABLE tbl_name ALTER COLUMN col_name SET DEFAULT default_value;ALTER TABLE tbl_name ALTER COLUMN col_name DROP DEFAULT;
はい
ロックフリーの列型変更
ALTER TABLE tbl_name MODIFY col_name TYPE, ALGORITHM = omc;はい
複数の
ALTER TABLE操作ALTER TABLE tbl_name MODIFY col_name_a, DROP COLUMN col_name_b;はい
生成列
-
いいえ
パーティションの変更
-
いいえ
CCI
CCI の作成
CREATE CLUSTERED COLUMNAR INDEX cci_name;ALTER TABLE tbl_name ADD CLUSTERED COLUMNAR INDEX cci_name;
はい
CCI の削除
DROP INDEX cci_name ON TABLE tbl_name;ALTER TABLE tbl_name DROP INDEX cci_name;
はい
CCI 名の変更
ALTER TABLE tbl_name RENAME INDEX cci_name_a TO cci_name_b;はい
CCI に RANGE パーティションを追加する
ALTER TABLE `tbl_name`.`cci_name` ADD PARTITION;はい
その他の CCI パーティションの変更
-
いいえ
ALTER TABLEを使用して列を変更する場合、次の制約が適用されます。ステートメント
プライマリキーを変更できますか?
インデックスパーティションキーを変更できますか?
ソートキーを変更できますか?
MODIFY COLUMN
はい
はい
はい
ALTER COLUMN SET DEFAULT, ALTER COLUMN DROP DEFAULT
はい
はい
はい
ADD COLUMN
いいえ
該当なし
該当なし
CHANGE COLUMN
いいえ
いいえ
いいえ
DROP COLUMN
いいえ
いいえ
いいえ
説明現在、CCI を含むテーブルで、列の変更に関連する ALTER TABLE ステートメントを実行できます。
バージョン 5.4.20-20250714 以降では、MODIFY COLUMN と列のデフォルト値の変更は、一部のプライマリキー、CCI パーティションキー、および CCI ソートキーの変更でサポートされています。
重要な列 (プライマリキー、CCI パーティションキー、または CCI ソートキー) を変更すると、CCI の完全な再構築がトリガーされる場合があります。 これは、大きなテーブルでは長時間実行される操作になる可能性があります。 これはデフォルトで無効になっています。 非同期実行を使用することをお勧めします。 この機能を使用するには、次のパラメーターを設定します。
# CCI の重要な列の変更を許可する SET ENABLE_MODIFY_CCI_CRITICAL_COLUMN = TRUE; # 重要な列の再構築ロジック。 0 は、システムがポリシーに基づいてロジックを自動的に選択することを示します。 この値は変更しないことをお勧めします。 SET REBUILD_CCI_STRATEGY = 0; # テーブルで許可される CCI の最大数。 テーブルに複数の CCI がすでに存在する場合は、この値をより大きな数に設定できます。 SET MAX_CCI_COUNT = 2;
次の表は、
MODIFY/CHANGE COLUMNステートメントでサポートされているデータ型について説明しています。サポートされている型
サポートされていない型
数値型:BIT (UNSIGNED)、TINYINT (UNSIGNED)、SMALLINT (UNSIGNED)、MEDIUMINT (UNSIGNED)、INT (UNSIGNED)、および BIGINT (UNSIGNED)
時間型:DATETIME、TIMESTAMP、TIME、および YEAR
浮動小数点数型:FLOAT、DOUBLE、DECIMAL、および NUMERIC
文字列型:CHAR、VARCHAR、TEXT、BINARY、VARBINARY、および BLOB
特殊型:JSON、ENUM、および SET
特殊型:POINT および GEOMETRY
説明列をサポートされていないデータ型に変更する場合は、
DROP INDEXステートメントを使用して CCI を削除し、列のデータ型を変更してから、CCI を再作成できます。次の表は、
ALTER TABLEステートメントを使用したインデックスの変更のサポートについて説明しています。文
サポート対象
ALTER TABLE ADD PRIMARY KEY
はい
ALTER TABLE ADD [UNIQUE/FULLTEXT/SPATIAL/FOREIGN] KEY
はい
ALTER TABLE DROP INDEX
はい
ALTER TABLE DROP FOREIGN KEY fk_symbol
はい
ALTER TABLE DROP PRIMARY KEY
いいえ。禁止されています。
ALTER TABLE RENAME INDEX
はい。CCI の名前を変更できます。
ALTER TABLE ALTER INDEX index_name {VISIBLE | INVISIBLE}
いいえ。CCI を変更することはできません。
ALTER TABLE {DISABLE | ENABLE} KEYS
いいえ。CCI を変更することはできません。
FAQ
ソートキーを指定せずに CCI を作成できますか?
A: いいえ。
CREATE CLUSTERED COLUMNAR INDEX文でソートキーを明示的に指定する必要があります。ソートキーとパーティションキーには、異なる列を指定できます。たとえば、t_orderテーブルに CCI を作成する場合、seller_idをソートキーとして、order_idをパーティションキーとして指定できます。パーティションキーを指定せずに CCI を作成できますか?
A:はい。パーティションキーを指定しない場合、デフォルトでプライマリキーがパーティションキーとして使用され、パーティションポリシーとして HASH が選択されます。
CCI の作成の進捗状況を確認するにはどうすればよいですか?
A:DDL 管理ステートメントを使用して、CCI の現在のステータスと DDL タスクの実行の進捗状況を表示できます。 詳細については、「SHOW COLUMNAR INDEX」および「SHOW DDL」をご参照ください。
CCI を削除するにはどうすればよいですか?
A:「DROP INDEX」ステートメントを使用して、CCI を削除できます。