MySQL の標準的なセカンダリインデックスのルックアップでは、通常 2 回の B ツリースキャンが必要となり、クエリの効率に影響を与える可能性があります。このパフォーマンスボトルネックに対処するため、PolarDB-X は Guess Primary Key Page No (GPP) 機能を導入しています。GPP は、プライマリキーのデータページを直接特定することでルックアップパスを最適化し、特定のシナリオではクエリのパフォーマンスを 50% 以上向上させることができます。
前提条件
インスタンスは、次の要件を満たす必要があります。
インスタンスエディション: Standard Edition または Enterprise Edition
エンジンバージョン: MySQL 8.0
データノードバージョン:
xcluster8.4.19-20240731以降 (2024 年 7 月 31 日 以降にリリースされたバージョン)。説明インスタンスバージョンの命名規則の詳細については、「リリースノート」をご参照ください。
インスタンスのバージョンを表示する方法の詳細については、「インスタンスのバージョンを表示および更新する」をご参照ください。
課金
GPP 機能は無料です。ただし、GPP は各セカンダリインデックスエントリに 4 バイトのオーバーヘッドを追加します。ほとんどのテーブルでは、これによりストレージが 5% 未満増加しますが、それに応じてストレージコストも増加します。
注意事項
インスタンスバージョン: GPP は、基盤となるストレージ構造を変更します。GPP が有効になっているインスタンスは、GPP をサポートしていない以前のバージョンにスペックダウンすることはできません。
既存のインデックス: GPP を有効にしても、既存のセカンダリインデックスは自動的に GPP 機能を使用しません。GPP を有効にするには、次のようにインデックスを再構築する必要があります。
新しいインデックスを作成します:
ALTER TABLE ... ADD INDEX idx_new ...;インデックスの名前を変更します:
ALTER TABLE ... RENAME idx TO idx_old, RENAME idx_new TO idx;元のインデックスを削除します:
ALTER TABLE ... DROP INDEX idx_old;
テーブルとインデックスタイプの制限: GPP は、一時テーブル、システムテーブル、圧縮テーブル、フルテキストインデックス、または空間インデックスには適用されません。
GPP 機能を有効にする
GPP 機能は、PolarDB-X インスタンスでデフォルトで有効になっています。この機能を有効または無効にするには、PolarDB-X コンソール に移動します。ターゲットクラスターの ページで、ストレージレイヤー タブをクリックし、opt_index_format_gpp_enabled パラメーターの値を変更します。この変更は、インスタンスを再起動しなくてもすぐに有効になります。
opt_index_format_gpp_enabledパラメーターをONに設定すると、テーブルまたは新しいセカンダリインデックスを作成するときに、GPP 機能を備えたセカンダリインデックスがデフォルトで作成されます。opt_index_format_gpp_enabledパラメーターをOFFに設定すると、テーブルまたは新しいセカンダリインデックスを作成するときに、標準のセカンダリインデックスが作成されます。これは、MySQL のコミュニティエディションと一致しています。
GPP パフォーマンステスト
Sysbench などの標準的なベンチマークツールは、通常、読み取り専用シナリオ (例: oltp_read_only) でプライマリキーによってクエリを実行しますが、これはセカンダリインデックスのルックアップをトリガーしません。GPP のパフォーマンス上の利点を正確に評価するために、テストでは、プライマリキー (id) の代わりにセカンダリインデックスキー (例: k) でクエリを実行するように変更し、現実的なルックアップシナリオをシミュレートしました。以下の表は、GPP が有効な PolarDB-X インスタンスとそうでないインスタンスの QPS (Queries Per Second) 改善率を示しています。
