PolarDB:アダプティブ実行プランの切り替え

背景情報

オプティマイザは、統計情報とサンプリングされたデータの一部に基づいてカーディナリティと選択率を見積もります。サンプリングの精度とサンプリング方法により、推定結果は実際の情報と異なる場合があります。また、さまざまなシナリオで統計情報が収集されない場合もあります。この場合、オプティマイザは経験値または数学的仮定に基づいて統計情報を見積もるため、推定値と実際の値の間に大きなずれが生じる可能性があります。オプティマイザの推定結果が実際の値と一致せず、不適切な実行プランが選択されたシナリオでは、オプティマイザは必要な情報を事前に簡単に収集できません。

アダプティブ実行プランの切り替え

アダプティブ行・列ルーティング

インメモリ列インデックス (IMCI) 機能を 自動行・列ルーティング を有効にして使用すると、行ストアノードでの低速クエリの推定実行コストが比較的低い場合、一部の低速クエリが行ストアノードにルーティングされる可能性があります。

この問題を解決するには、次のいずれかのソリューションを使用できます。

• 列ストアノードにルーティングされるクエリの コストしきい値 を下げます。ただし、このソリューションを使用すると、多数の短いクエリが列ストアノードにルーティングされます。その結果、列ストアノードの負荷が高くなり、他のクエリがブロックされます。

• ステートメント アウトライン 機能を使用して、固定テンプレートを持つクエリを列ストアノードにルーティングします。たとえば、次のサンプルステートメントに記載されているアウトラインを追加して、クエリを強制的に列ストアノードにルーティングできます。ただし、このソリューションでは、O&M コストが大幅に増加します。

  CALL dbms_outln.add_optimizer_outline("<Schema_name>", "/*+ SET_VAR(cost_threshold_for_imci=0) SET_VAR(imci_ap_threshold=0) */","<query>");

PolarDB for MySQL のアダプティブ実行プラン切り替え機能は、アダプティブ行・列ルーティングに適用して、行ストアノードに誤ってルーティングされた低速クエリを列ストアノードに自動的に切り替え、実行効率を向上させることができます。次の図に示すように、アダプティブ実行プラン切り替え機能を使用する場合、データベースは最適化フェーズで各クエリブロックとクエリ全体でスキャンされる行数にマークを付け、それらをモニタリング情報に追加します。コスト計算後に IMCI が選択されない場合、オプティマイザはアダプティブ実行プラン切り替え機能をトリガーするためのしきい値を計算します。新しいバージョン (8.0.1.1.49 以降、または 8.0.2.2.29 以降など) では、このしきい値は loose_adaptive_cost_threshold_for_imci パラメータに基づいて計算されます。以前のクラスタバージョンでは、loose_cost_threshold_for_imci パラメータに基づいて計算されます。実行フェーズでは、クエリブロックまたはクエリ全体でスキャンされた行数がアダプティブ実行プラン切り替え機能をトリガーするためのしきい値に達すると、システムは列ストア実行に切り替えるかどうかを確認します。コアーパスでスキャンされた行をモニタリングする際には、整数を比較するだけで、実行パフォーマンスには影響しません。列ストア実行に切り替える前に、オプティマイザは行ストア実行の結果セットがクライアントに返されないことを確認します。列ストア実行に切り替えた後、システムはキャッシュされた結果セットをクリアします。

順序付けられたインデックスのアダプティブ選択

データベースクエリの最適化では、prefer_ordering_index 最適化により、ソート操作をサポートするインデックスが優先されます。ただし、場合によっては、この最適化によってクエリのパフォーマンスが低下する可能性があります。特に、順序付けられたインデックスとクエリの選択性が一致しない場合、選択性が低いか、大量のデータスキャンとテーブルルックアップを必要とする順序付けられたインデックスを選択すると、クエリが関連のない大量のデータをスキャンし、I/O および CPU ワークロードが増加する可能性があります。

次のソリューションは、prefer_ordering_index 最適化によって発生する低速クエリに対処できます。

ステートメント アウトライン 機能を使用して、特定の SQL テンプレートの prefer_ordering_index 最適化を無効にすることができます。ただし、このソリューションでは、O&M コストが大幅に増加します。さらに、SQL テンプレートを使用し、prefer_ordering_index 最適化を有効にした方がパフォーマンスが向上する一部のクエリに影響します。

CALL dbms_outln.add_optimizer_outline("<Schema_name>", "/*+ SET_VAR(optimizer_switch='prefer_ordering_index=off') */","<query>");

アダプティブ実行プラン切り替え機能は、順序付けられたインデックスのアダプティブ選択に適用できます。 prefer_ordering_index 最適化によってクエリのパフォーマンスが低下した場合、実行プランは順序付けられたインデックスを破棄します。クエリが prefer_ordering_index 最適化のために順序付けられたインデックスを選択した場合、オプティマイザはアダプティブ実行プラン切り替え機能をトリガーするためのしきい値を計算します。実行フェーズでは、順序付けられたインデックスで実行された行数がアダプティブ実行プラン切り替え機能をトリガーするためのしきい値に達すると、システムは列ストア実行に切り替えるかどうかを確認します。コアーパスでスキャンされた行をモニタリングする際には、整数を比較するだけで、実行パフォーマンスには影響しません。列ストア実行に切り替える前に、オプティマイザは行ストア実行の結果セットがクライアントに返されないことを確認します。列ストア実行に切り替えた後、システムはキャッシュされた結果セットをクリアします。

前提条件

• アダプティブ行・列ルーティング (imci_chosen=on 値に対応) を有効にするには、クラスタが次の要件を満たしている必要があります。

  • PolarDB for MySQL 8.0.1 リビジョンバージョン 8.0.1.1.39 以降。

  • PolarDB for MySQL 8.0.2 リビジョンバージョン 8.0.2.2.29 以降。

• 順序付けられたインデックスのアダプティブ選択 (ordering_index=on 値に対応) を有効にするには、クラスタが次の要件を満たしている必要があります。

  • PolarDB for MySQL 8.0.1 リビジョンバージョン 8.0.1.1.47 以降。

  • PolarDB for MySQL 8.0.2 リビジョンバージョン 8.0.2.2.29 以降。

使用上の注意

アダプティブ実行プラン切り替え機能を有効または無効にする

PolarDB コンソール にログインします。 [パラメータ] ページでアダプティブ実行プラン切り替え機能を設定します。

• パラメータ loose_adaptive_plans_switch を 'imci_chosen=on' に設定して、アダプティブ行・列ルーティングを有効にします。

• パラメータ loose_adaptive_plans_switch を 'ordering_index=on' に設定して、prefer_ordering_index 最適化によって選択された順序付けられたインデックスのアダプティブ選択を有効にします。

• パラメータ loose_adaptive_plans_switch を 'imci_chosen=on,ordering_index=on' に設定して両方のモードを有効にするか、いずれかを 'off' に設定して対応するモードを無効にします。

詳細については、「クラスタとノードのパラメータを設定する」をご参照ください。次の表に、設定できるパラメータを示します。

アダプティブ切り替えの実行回数を表示する

次のステートメントを実行して、アダプティブ切り替えの実行回数を表示できます。

SHOW GLOBAL STATUS LIKE 'Adaptive_plan_used';

次の表に、Adaptive_plan_used 変数を示します。