PolarDB:適応実行プランの切り替えAdaptive execution plan switching

背景情報

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

インメモリ列インデックス (IMCI) 機能を使用すると、ローストアノードでの低速クエリの推定実行コストが比較的低い場合に、一部の低速クエリがローストアノードにルーティングされることがあります。 詳細については、「IMCI」および「行ストアおよび列ストアノード間のHTAPベースのリクエスト分散」をご参照ください。

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

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

• ステートメントアウトライン機能を使用して、固定テンプレートを持つクエリを列ストアノードにルーティングします。 たとえば、次のサンプルステートメントで説明するアウトラインを追加して、クエリを列ストアノードに強制的にルーティングできます。 ステートメントアウトライン機能の詳細については、「ステートメントアウトライン」をご参照ください。 しかしながら、この解決策は、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によって提供されるアダプティブ実行プラン切り替え機能は、実行のために行ストアノードに誤ってルーティングされた低速クエリを列ストアノードに自動的に切り替えることができます。 これにより、実行効率が向上する。

仕組み

データベースは、最適化フェーズ中にクエリブロックとスキャンする行の総数を監視情報に追加するために、適応実行プラン切り替え機能を使用します。 コスト計算後に列ストアノードでSQL文が実行されない場合、オプティマイザはアダプティブスイッチングをトリガーするしきい値を計算します。 実行フェーズで、クエリブロックまたはスキャンされる行の総数が計算されたしきい値をトリガーする場合、エグゼキュータは、実行のためにステートメントを列ストアノードに切り替えるかどうかを決定します。 実行のためにステートメントを列ストアノードに切り替える前に、オプティマイザは、行ストアノード上のステートメントの実行結果セットがクライアントに返されないようにします。 ステートメントが実行のために列ストアノードに切り替えられた後、PolarDBはキャッシュされた結果セットをクリアします。

前提条件

クラスターは、リビジョンバージョンが8.0.1.1.39以降のPolarDB for MySQL 8.0.1を実行します。

使用上の注意

アダプティブ実行プラン切り替え機能の有効化または無効化

にログインします。PolarDBコンソール. 管理するクラスターの [パラメーター] ページで、loose_adaptive_plans_switchパラメーターを 'imci_chopped=on' に設定して、アダプティブ実行プランの切り替え機能を有効にします。 詳細については、「クラスターとノードパラメーターの設定」をご参照ください。 次の表に、構成可能なパラメーターを示します。

データベースでアダプティブスイッチングが発生した回数の表示

次のステートメントを実行して、データベースでアダプティブスイッチングが発生した回数を表示できます。

「Adaptive_plan_used」のようなグローバルステータスを表示します。

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