クエリオプティマイザの概要 - PolarDB - Alibaba Cloud ドキュメントセンター

クエリオプティマイザーは、論理プランを最適化して物理プランを生成します。主なフェーズには、SQLの書き換えとプランの列挙が含まれます。

次の図は、構造化照会言語 (SQL) ステートメントを受け取った後の実行プロセスを示しています。

Execution process after an SQL statement is received

構文パーサーは、SQLテキストを抽象構文ツリー (AST) に解析します。
構文木は、関係代数ベースの論理計画に変換される。
オプティマイザは、論理計画を最適化して物理計画を生成する。
エグゼキュータは、このプランを実行してクエリ結果を取得し、クエリ結果をクライアントに返します。

このトピックでは、クエリオプティマイザの動作について説明します。次の側面が含まれています。

関係代数演算子
SQLの書き換え (ルールベースのオプティマイザ (RBO) フェーズ)
クエリプラン列挙 (コストベースオプティマイザー (CBO) フェーズ)

関係代数演算子

データベースシステムでは、SQLクエリは、通常、関係代数演算子からなるツリーとして表される。次のシナリオの演算子を使用できます。

Project: 関数計算を含む、SQLのSELECT列を記述するために使用されます。
フィルター: SQLのWHERE条件を記述するために使用されます。
JOIN: SQLでJOINを記述するために使用されます。対応する物理演算子は、HashJoin、BKAJoin、Nested-Loop Join、およびSortMergeJoinです。
Agg: SQLのGroup By関数と集計関数を記述するために使用されます。対応する物理演算子はHashAggとSortAggです。
並べ替え: SQLの順序と制限を記述するために使用されます。対応する物理演算子はTopNとMemSortです。
LogicalView: PolarDB-X 1.0によってストレージ層MySQLに送信するSQL文を記述するために使用されます。 SQLステートメントは、1つまたは複数の論理演算子を含み得る。
Gather: 複数のデータストリームからデータを収集する操作を表します。このGather演算子は通常、LogicalViewの上に表示されます。並列実行が有効になっている場合、並列最適化ステップでGather演算子がプルアップされます。

次のクエリSQL文を例として使用します。ステートメントは、TPC-Hクエリ3を変更することによって得られる。

SELECT l_orderkey, sum(l_extendedprice *(1 - l_discount)) AS収益
顧客、注文、LINEITEMから
c_mktsegment = 'AUTOMOBILE'
  とc_custkey = o_custkey
  とl_orderkey = o_orderkey
  およびo_orderdate <''1995-03-13'
  およびl_shipdate > '1995-03-13'
グループBY l_orderkey;

次のEXPLAINコマンドを実行して、PolarDB-X 1.0の実行計画を表示します。

HashAgg(group="l_orderkey", revenue="SUM(*)")
  HashJoin(condition="o_custkey = c_custkey", type="inner")
    収集 (concurrent=true)
      LogicalView(tables="ORDERS_[0-7],LINEITEM_[0-7]", shardCount=8, sql="SELECT 'ORDERS'.'o_custkey', 'LINEITEM'.'l_orderkey', ('LINEITEM'.'l_extendedprice' *? -'LINEITEM'.'l_discount') AS 'x' FROM 'ORDERS' AS 'ORDERS' INNER JOIN 'LINEITEM' AS 'LINEITEM' ON ((('ORDERS'.'o_orderkey' = 'LINEITEM'.'_) 'LINEIDE.'?'__(')' ('ORRRSDEIRDEIDEIDEIDEIDERS') ')'? '?'_(''__) ''
    収集 (concurrent=true)
      LogicalView(tables="CUSTOMER_[0-7]" 、shardCount=8、sql="SELECT 'c_custkey' FROM 'CUSTOMER' AS 'CUSTOMER' WHERE ('c_mktsegment' = ?)")

次のツリーマップグラフは、実行計画を示しています。

Treemap chart that illustrates the relational algebra operators

説明左側のLogicalView演算子には、実際には、ORDERSとLINEITEMの2つのテーブルに対するJOIN演算が含まれています。EXPLAIN結果のLogicalViewのSQL属性も、このJOIN操作を反映しています。

SQL書き換え (RBO)

SQL書き換えフェーズでは、入力は論理実行プランであり、出力は論理実行プランです。このステップでは、いくつかのヒューリスティックルールが主に適用され、RBOが使用される。したがって、このステップは、通常、RBOフェーズとも呼ばれる。

SQL書き換えステップには、次の主な機能があります。

サブクエリのネスト解除
サブクエリアンネスティングは、相関アイテムを含む相関サブクエリをSemiJoinまたは同様の演算子として表すことです。これは、ストレージ層MySQLまたは層で実行するためのアルゴリズムを選択するPolarDB − X 1.0にプッシュダウンするなど、様々な後続の最適化を容易にする。次の例では、InサブクエリはSemiJoin演算子に変換され、最終的にPolarDB-X 1.0が実行される物理SemiHashJoin演算子に変換されます。
```
> 説明するt1からidを選択する (t2からidを選択するe t2.name = 'hello');
SemiHashJoin(condition="id = id", type="semi")
  収集 (concurrent=true)
    LogicalView(tables="t1", shardCount=2, sql="SELECT 'id' FROM 't1' AS 't1'")
  収集 (concurrent=true)
    LogicalView(tables="t2_[0-3]", shardCount=4, sql="SELECT 'id' FROM 't2' AS 't2' WHERE ('name' = ?)") 
```

オペレータpushdown

オペレータプッシュダウンは重要なステップです。PolarDB-X 1.0には、以下の演算子プッシュダウン用の最適化ルールが組み込まれています。

最適化ルール	説明
予測プッシュダウンまたは列の剪定	フィルターとプロジェクトの演算子を実行のためにストレージ層MySQLにプッシュダウンし、不要な行と列を除外します。
クラスタリングに参加	シャーディングメソッドを使用し、シャードキーの等価条件に基づいてJOIN操作を再ソートおよびクラスター化します。これは、JOIN動作のその後のプッシュダウンを容易にする。
プッシュダウンに参加する	条件を満たすJOIN操作を実行のためにストレージレイヤーMySQLにプッシュダウンします。
Aggプッシュダウン	Agg操作をFinalAggとLocalAggの2つのフェーズに分割し、LocalAggをストレージレイヤーMySQLにプッシュダウンします。
プッシュダウンの並べ替え	ソート操作をMergeSortとLocalSortの2つのフェーズに分割し、LocalSortをストレージレイヤーMySQLに押し下げます。

クエリのプッシュダウンの詳細については、「SQLの書き換えとプッシュダウン」をご参照ください。

クエリプラン列挙 (CBO)

SQL書き換えフェーズで生成された論理実行プランは、plan Enumeratorの入力として使用されます。次に、Plan Enumeratorは最終的な物理実行プランを生成します。 Plan Enumeratorは、事前定義されたコストモデルを使用して、複数の実行可能なクエリプランからコストが最小のクエリプランを選択します。 SQL書き換えフェーズとは異なり、Plan Enumeratorでは、ルールに基づいて、より良いまたはより悪い実行プランを生成することができます。コスト比較結果に基づいて、より良い実行計画が選択される。したがって、Plan EnumeratorはCBOとも呼ばれます。

CBOのコアコンポーネントには、次の部分があります。

統計値
カーディナリティの推定
変換ルール
コストモデル
スペース検索エンジンを計画する

CBOプロセスは、ロジックに関して次の手順で構成されています。

検索エンジンは、変換ルールを使用して入力論理実行プランを変換し、物理実行プランの検索空間を構築します。
次に、コストモデルを使用して、探索空間内の各実行プランのコストを推定し、最小コストを有する物理実行プランを選択する。
コスト推定プロセスは、カーディナリティ推定から分離することはできません。カーディナリティ推定では、各テーブルおよび各列の統計に基づいて、入力行数および選択率などの各演算子に関する情報が推定される。次いで、推定された情報は、クエリプランのコストを推定するために、オペレータのコストモデルに提供される。