ローカルインデックスとグローバルインデックスの比較
ローカルインデックスと比較して、グローバルインデックスは独立したパーティションルールを持つため、インデックステーブルのあるパーティションのインデックス値が、プライマリテーブルの複数のパーティションにまたがるデータに対応する可能性があります。インデックスのパーティションルールとプライマリテーブルのパーティションルールが必ずしも同じでないため、分散環境ではインデックスデータとプライマリテーブルデータの格納場所が常に一緒である保証もなく、これにより読み書きのRPCコストや分散トランザクションのコストが必然的に発生します。例えば、プライマリテーブルのパーティションとグローバルインデックスのパーティションが同一の物理的場所にない場合、TABLE SCAN 演算子がグローバルインデックステーブルをスキャンする際には、リモートマシンへのRPC操作を1回含み、そこからプライマリテーブルデータを取得します。そのため、グローバルインデックスはローカルインデックスに比べてメンテナンスコストが高くなります。プライマリテーブルのパーティションルールを十分に評価し、適切なパーティションキーを選択し、できるだけ多くのクエリ条件がプライマリテーブルのパーティションキーをカバーするようにすることで、グローバルインデックスの使用を可能な限り回避する必要があります。
使用上の制限
OceanBaseデータベースのテーブルはインデックス組織テーブル(IOT)であるため、パーティションテーブルにおいては、指定された主キーに対するクエリがテーブルのパーティションを迅速に特定できるようにするため、パーティションキーは主キーの部分集合でなければなりません。パーティションテーブルにローカルパーティション一意インデックス(Local Partitioned Unique Index)を作成する必要がある場合、そのインデックスキーにはプライマリテーブルのパーティションキーが含まれている必要がありますが、グローバルパーティション一意インデックス(Global Partitioned Unique Index)にはこの制限はありません。
例:
obclient> CREATE TABLE test(pk int,c2 int ,c3 int, PRIMARY KEY(pk)) PARTITION BY hash(pk) partitions 5;
Query OK, 0 rows affected
obclient> CREATE UNIQUE INDEX idx ON test(c2) LOCAL;
ERROR 1503 (HY000): A UNIQUE INDEX must include all columns in the table's partitioning function
obclient> CREATE UNIQUE INDEX idx ON test(c2, pk) LOCAL;
Query OK, 0 rows affected
obclient> DROP INDEX idx ON test;
Query OK, 0 rows affected
obclient> CREATE UNIQUE INDEX idx ON test(c2) GLOBAL;
Query OK, 0 rows affected