インデックスは、サブインデックスとも呼ばれ、オプションの構造です。ユーザーは業務ニーズに応じて特定のフィールドにインデックスを作成することで、それらのフィールドに対するクエリの速度を向上させることができます。この章では、インデックスの利点と欠点、可用性と可視性、およびインデックスとキーの関係について説明します。
OceanBaseデータベースは聚集インデックステーブルモデルを採用しており、ユーザーが指定した主キーに対しては自動的に主キーインデックスが生成されます。一方、ユーザーが作成するその他のインデックスはサブインデックスとなります。
以下の例のように、EMPLOYEE テーブルを作成し、3組のデータを挿入します。
obclient> CREATE TABLE EMPLOYEE(id INT, name VARCHAR(20), PRIMARY KEY(id));
obclient> INSERT INTO EMPLOYEE VALUES(1,'John'),(2,'Alice'),(3,'Bob');
obclient> SELECT * FROM EMPLOYEE;
EMPLOYEE テーブルでは、ユーザーが指定した id に従ってデータが順序付けられて保存されます。データの検索時には、id を基に二分探索を行うことで、特定のデータを迅速に特定できます。name フィールドでの高速検索が必要な場合は、name フィールドにサブインデックスを作成できます。以下の例のように：
CREATE INDEX IDX_NAME ON EMPLOYEE(name);
インデックステーブルのデータは以下のとおりです：
name: Alice, id: 2
name: Bob, id :3
name: John, id: 1
インデックステーブル name_index では、name フィールドに従ってデータが順序付けられて保存されます。ユーザーが name フィールドで検索を指定すると、二分探索を行うことで、特定のデータを迅速に特定できます。
インデックスの利点と欠点
インデックスの利点は以下のとおりです：
SQLステートメントを変更することなく、ユーザーが必要とするデータのみをスキャンすることで、クエリを高速化できます。
インデックスに格納される列数は通常少ないため、クエリI/Oを節約できます。
インデックスの欠点は以下のとおりです：
どのフィールドにインデックスを作成するかを選択するには、業務とデータモデルについて深い理解が必要です。
業務が変更された場合、以前に作成したインデックスがニーズを満たしているかどうかを再評価する必要があります。
データを書き込む際には、インデックステーブル内のデータをメンテナンスする必要があり、一定のパフォーマンスコストが発生します。
インデックステーブルはメモリ、ディスクなどのリソースを消費します。
インデックスの可用性と可視性
インデックスの可用性
Truncateパーティション/削除パーティション時、OceanBaseデータベースは対応するテーブルのすべてのグローバルインデックスを再構築します。再構築中は、一時的に利用できなくなります。
インデックスの可視性
インデックスの可視性とは、オプティマイザーがそのインデックスを無視するかどうかを指します。インデックスが不可視の場合、オプティマイザーはそのインデックスを無視しますが、DML操作ではインデックスのメンテナンスが必要です。一般的に、インデックスを削除する前に、まずインデックスを不可視に設定し、業務への影響を観察します。影響がないことを確認した後、インデックスを削除します。
インデックスとキーの関係
キーとは、一連の列または式を指し、ユーザーはキーにインデックスを作成できます。しかし、インデックスとキーは異なります。インデックスはデータ内に格納されるオブジェクトであり、キーは論理的な概念です。
関数インデックス
テーブルの1列または複数列の値に基づいて計算された結果に基づいて作成されるインデックスを関数インデックスと呼びます。関数インデックスは最適化技術の一種であり、関数インデックスを使用することで、クエリ時に一致する関数値を迅速に特定し、重複計算を回避してクエリ効率を向上させることができます。
カラムストアインデックス
カラムストアインデックスは、インデックステーブル内のデータをカラムストア形式で保存するものです。OceanBaseデータベースでは、テーブル作成時にその保存形式をカラムストアとして指定できます。インデックスもデータテーブルと同様にテーブルであるため、インデックステーブル内のデータもカラムストア形式で保存する設定が可能です。
カラムストアの詳細については、カラムストアを参照してください。