GSIの概要 - PolarDB - Alibaba Cloud ドキュメントセンター

PolarDB for MySQLでは、パーティションテーブルにグローバルセカンダリインデックス (GSI) を作成できます。 GSIを使用すると、パーティションテーブルを共通テーブルとして使用し、プライマリキーに加えて代替キーを使用してデータクエリとアクセスを有効にできます。

説明

GSIの特徴はカナリアの解放段階にあります。この機能を使用するには、クォータセンターに移動します。 クォータIDフィールドにpolardb_mysql_gsiと入力してクォータ名を見つけます。次に、[操作] 列の [適用] をクリックします。
GSIの詳細については、DingTalkグループ24490017825に参加してテクニカルサポートを取得してください。

背景情報

従来、ローカルインデックスは分割テーブルで使用されます。ローカルインデックスは、パーティションテーブルの個々のパーティション内でのみデータをソートしてアクセスする方法を提供します。テーブルのすべてのパーティションにわたるデータの並べ替えはできません。ローカルで一意なインデックスを作成するには、インデックスフィールドにすべてのパーティションキーを含める必要があります。

パーティションテーブルにローカルインデックスのみが含まれている場合、パーティションキーの制限により、テーブルに次の問題が発生する可能性があります。

クエリ条件でパーティションキーが指定されていない場合、パーティションテーブル上のすべてのパーティションがデータクエリのためにスキャンされます。これは読み取り増幅を引き起こし、これはパーティションの数と共に増加する。
インデックスによってソートされる必要があるデータは、データが各パーティション内のインデックスによってソートされていても、クロスパーティションクエリではソートされない可能性があります。グローバルソートがトリガされ得る。
ローカルに一意のインデックスには、すべてのパーティションキーを含める必要があります。そうでない場合、インデックスはすべてのパーティション間でグローバルに一意ではありません。

PolarDB for MySQLでは、個々のパーティションに限定されるローカルインデックスとは異なり、グローバルインデックスはすべてのテーブルパーティションにわたってデータをソートします。グローバルに一意のインデックスを作成するために、インデックスフィールドにすべてのパーティションキーを含める必要はありません。

前提条件

クラスターは、リビジョンバージョンが8.0.2.2.7以降のPolarDB for MySQL 8.0.2を実行します。クラスターのバージョンを照会するには、エンジンバージョントピックの「エンジンバージョンの照会」を参照してください。

制限

GSIは、InnoDBエンジンを使用するパーティションテーブルでのみ作成できます。ハイブリッドパーティションテーブルでGSIを作成することはできません。
GSIをフルテキストインデックスまたは空間インデックスにすることはできません。
圧縮テーブル、一時テーブル、暗号化テーブル、または冗長行ストア形式または圧縮行ストア形式を使用するテーブルに対してGSIを作成することはできません。
GSIが作成される列は、パーティションテーブルの主キーにはできません。
GSIが作成されるパーティションテーブルは、生成された列をサポートしません。
範囲パーティションまたはリストパーティションの作成を除いて、パーティションレベルのDDLステートメントを実行すると、既存のGSIは無効になります。パーティションテーブルの既存のGSIをすべて削除してから、GSIを再作成する必要があります。 UPDATE GLOBAL INDEXステートメントを実行してGSIを再作成することもできます。

機能強化

パラレルDDL機能を使用して、GSIを並行して作成できます。
GSIが作成されるパーティションテーブルは、Instant ADD COLUMN機能をサポートしています。
グローバルセカンダリインデックスの範囲またはリストパーティション分割テーブルを作成した場合、パーティションを追加するときにパーティションレベルのメタデータロック (MDL) がサポートされます。
GSIが作成されているテーブルを間隔範囲パーティションテーブルに変換するか、interval rangeパーティションテーブルにGSIを作成できます。
GSIが作成されているパーティションテーブルでパーティションレベルのDDLステートメントを実行する場合、UPDATE GLOBAL INDEXステートメントを実行してGSIを再作成できます。例：
1. パーティションキーとしてフィールドを使用するt1という名前のレンジパーティションテーブルを作成します。 bフィールドにk1という名前のGSIを作成します。
```
テーブルの作成t1 (
  INT PRIMARYキー、
  b INT、
  インデックスk1(b) グローバル
) レンジによるパーティー ('a')
(PARTITION p0の値は (5) エンジン=InnoDB、
 PARTITION p1値が (10) エンジン=InnoDB); 
```
2. テーブルt1のパーティションp1を削除し、GSIを再作成します。
```
ALTER TABLE t1 DROP PARTITION p1更新グローバルインデックス;
```

構文

インデックス名の後にlocalまたはglobalキーワードを追加することで、ローカルインデックスまたはグローバルインデックスを作成できます。

説明

インデックスの作成時にGLOBALキーワードを指定しないと、ローカルインデックスが作成されます。

例

パーティションキーとしてフィールドを使用するt1という名前のパーティションテーブルを作成します。 bフィールドにk1という名前のグローバルインデックスを作成します。
```
テーブルの作成t1 (
  INT PRIMARYキー、
  b INT、
  インデックスk1(b) グローバル
) ハッシュによるパーティー (a) パーティー3; 
```
パーティションキーとしてフィールドを使用するt1という名前のパーティションテーブルを作成します。次に、テーブルt1のbフィールドにk1という名前のグローバルインデックスとk2という名前のグローバル一意インデックスを作成します。
```
テーブルの作成t1 (
  INT PRIMARYキー、
  b INT
) ハッシュによるパーティー (a) パーティー3;

ALTER TABLE t1 ADD INDEX k1(b) グローバル;

t1(b) グローバルで一意のインデックスk2を作成します。
```

パフォーマンステスト

テストテーブル

同じスキーマを使用し、100万個のデータエントリを含む2つのパーティションテーブルを作成します。一方のテーブルにローカルインデックスを作成し、もう一方のテーブルにGSIを作成します。

次の例では、mytest1.big_table_1およびmytest2.big_table_1パーティションテーブルが作成されています。ローカルインデックスはmytest1.big_table_1テーブルに作成され、GSIはmytest2.big_table_1テーブルに作成されます。

CREATE TABLE mytest1.big_table_1 (
  INT PRIMARYキー、
  b INT、
  c INT、
  インデックスk1(b) ローカル
) ハッシュによるパーティション (a) パーティション32;

テーブルの作成mytest2.big_table_1 (
  INT PRIMARYキー、
  b INT、
  c INT、
  インデックスk1(b) グローバル
) ハッシュによるパーティション (a) パーティション32;

テスト方法

2つのテーブルのクエリ条件でパーティションキーを含まないSELECT、UPDATE、およびDELETEステートメントを実行します。パーティションの数が異なる2つのテーブルでステートメントを実行するのに必要な時間をテストします。

テスト結果

2つのテーブルのクエリ条件でパーティションキーを含まないSELECTステートメントを実行するのに必要な時間。
2つのテーブルのクエリ条件でパーティションキーを含まないUPDATEステートメントを実行するのに必要な時間。
2つのテーブルのクエリ条件でパーティションキーを含まないDELETEステートメントを実行するのに必要な時間。

上記のテスト結果は、GSIが作成されるパーティションテーブルでステートメントを実行するのに必要な時間が短くなることを示しています。テーブルに多くのデータが含まれている場合、実行時間の差は大きくなります。