グローバルセカンダリインデックス（GSI）を使用すると、PolarDB-X のテーブルに追加のシャーディングディメンションを導入でき、シャードキー以外の列に対するクエリでも全シャード横断スキャンを回避できます。各 GSI は、インデックステーブルによって実現され、PolarDB-X は XA トランザクションを用いて、このインデックステーブルとプライマリテーブルの同期を保ちます。
仕組み
分散データベースでは、各論理テーブルがシャードキーに基づいて複数のシャードに分割されます。クエリでシャードキー以外の列をフィルター条件として指定した場合、PolarDB-X はすべてのシャードをスキャンする必要があります（クロスシャードクエリ）。テーブルサイズおよびトラフィックの増加に伴い、このようなスキャンはクエリ遅延や接続プールの枯渇を引き起こします。
GSI は、インデックス対象の列でシャーディングされた別個のインデックステーブルを維持することでこの課題を解決します。PolarDB-X はクエリをインデックステーブル内の該当シャードに直接ルーティングし、必要に応じてのみプライマリテーブルから一致する行をフェッチします。
主な機能
| 機能 | 説明 |
|---|---|
| 追加のシャーディングディメンション | プライマリテーブルのシャードキーとは異なる列をインデックス化し、クロスシャードスキャンを回避したクエリルーティングを実現 |
| グローバル一意なインデックス | すべてのシャードにわたって一意性制約を適用 |
| 強力な一貫性 | XA トランザクションにより、インデックステーブルとプライマリテーブルが常時同期される |
| カバリングカラム | インデックステーブルに追加のカラムを含めることで、プライマリテーブルへの参照（ルックアップ）を回避 |
| オンラインスキーマ変更 | プライマリテーブルのロックを発生させずに GSI を追加 |
| インデックスヒント | 使用するインデックスを明示的に指定可能。PolarDB-X がプライマリテーブル参照の必要性を自動判定 |
よくある質問
GSI はどのような課題を解決しますか？
クエリ対象の列がプライマリテーブルのシャードキーと異なる場合、PolarDB-X はクロスシャードクエリを実行します。規模が拡大すると、これによりクエリの遅延や接続プールの枯渇が発生します。GSI は代替のシャーディングディメンションを追加することでクロスシャードクエリを削減し、クエリをインデックステーブル内の特定のシャードにターゲット指定できるようにします。
GSI を作成する際は、プライマリテーブルのシャードキーとは異なるシャードキーを選択してください。詳細については、「グローバルセカンダリインデックスの使用」をご参照ください。
GSI とローカルセカンダリインデックス（LSI）の違いは何ですか？
GSI では、インデックス行がデータ行とは異なるシャードに格納されます。GSI は関連データを保持するシャードを特定し、クエリをそのシャードにルーティングすることで、シャード境界を越えた効率的なクエリを実現します。
一方、LSI ではインデックス行がデータ行と同じシャードに格納されます。PolarDB-X 1.0 において、LSI は物理テーブル上の MySQL セカンダリインデックスを指します。PolarDB-X 1.0 が GSI を用いてクエリを単一のシャードにルーティングした場合、そのシャード上の LSI がさらにシャード内でのクエリパフォーマンスを向上させます。