PolarDB:実行計画の管理

プランキャッシュ

プランキャッシュはデフォルトで有効になっています。各 SQL ステートメントをパラメーター化し (定数を ? に置き換える)、結果の実行計画をキャッシュします。同じクエリパターンが後続で実行されると、PolarDB-X 1.0 は最適化をスキップし、キャッシュされたプランを再利用します。

クエリがプランキャッシュにヒットしたかどうかを確認するには、ステートメントに対して EXPLAIN を実行し、HitCache フィールドを確認します。

• HitCache:true — プランはキャッシュから提供されました。

• HitCache:false — オプティマイザーが新しいプランを生成しました (キャッシュがバイパスされたか、まだ生成されていませんでした)。

プラン管理とベースライン

プラン管理は、プランキャッシュを通過する複雑なクエリを処理します。各パラメーター化された SQL ステートメントは 1 つのベースラインにマッピングされ、ベースラインには 1 つ以上の実行計画が保持されます。ベースライン内のプランはディスクに永続化され、バージョンアップグレード後も維持されます。

実行計画がプラン管理に入ると、SQL プラン管理 (SPM) は次のように評価します。

• プランが既知の場合、SPM はそのコストが利用可能なプランの中で最小であるかどうかを確認します。

• プランが未知の場合、SPM はその最適化の度合いを評価するために実行するかどうかを決定します。

ベースラインに複数のプランが存在する場合、SPM はコストが最も低いプランを選択します。自動プラン展開中、SPM はデータの変更後やバージョンアップグレード後にコストベースオプティマイザー (CBO) によって発見されたより良いプランをベースラインに追加します。

BASELINE LIST の出力フィールド

BASELINE LIST を使用して、現在のすべてのベースラインを表示します。出力には次のカラムが含まれます。

ステップ 1：現在のプランの確認

EXPLAIN を実行して、アクティブな実行計画を確認します。

mysql> EXPLAIN SELECT * FROM lineitem JOIN part ON l_partkey=p_partkey WHERE p_name LIKE '%green%';

出力は、プランが ParallelHashJoin を使用し、HitCache:true であることを示しており、プランがプランキャッシュから提供されたことを確認できます。

Gather(parallel=true)
  ParallelHashJoin(condition="l_partkey = p_partkey", type="inner")
    LogicalView(tables="[00-03].lineitem", ...)
    LogicalView(tables="[00-03].part", ..., sql="... WHERE (`p_name` LIKE ?)", ...)
HitCache:true

BASELINE LIST を実行して、このステートメントに対してプランが 1 つしか存在しないことを確認します。

mysql> BASELINE LIST;
+-------------+---------------------------------------------+-----------+-------------------+-------+----------+
| BASELINE_ID | PARAMETERIZED_SQL                           | PLAN_ID   | EXTERNALIZED_PLAN | FIXED | ACCEPTED |
+-------------+---------------------------------------------+-----------+-------------------+-------+----------+
| -399023558  | SELECT * FROM lineitem JOIN part ON ...     | -935671684| Gather(...)       |     0 |        1 |
+-------------+---------------------------------------------+-----------+-------------------+-------+----------+

ステップ 2：ヒントを使用した代替プランのテスト

特定のデータ条件下で Batched Key Access (BKA) JOIN のパフォーマンスが向上する場合、ベースラインにコミットする前に、ヒント付きで EXPLAIN を実行してテストします。

mysql> EXPLAIN /*+TDDL:BKA_JOIN(lineitem, part)*/ SELECT * FROM lineitem JOIN part ON l_partkey=p_partkey WHERE p_name LIKE '%green%';

出力は、プランが ParallelBKAJoin に切り替わったことを確認します。HitCache:false であることに注意してください。これは、ヒントがプランキャッシュをバイパスしたことを意味します。

Gather(parallel=true)
  ParallelBKAJoin(condition="l_partkey = p_partkey", type="inner")
    LogicalView(tables="[00-03].lineitem", ...)
    Gather(concurrent=true)
      LogicalView(tables="[00-03].part", ...)
HitCache:false

ヒントはこの 1 回の実行で JOIN アルゴリズムを変更しますが、ベースラインには影響しません。

ステップ 3：ベースラインへの代替プランの追加

CBO がコストに基づいて選択できるように BKA JOIN プランを利用可能にするには、それをベースラインに追加します。

mysql> BASELINE ADD SQL /*+TDDL:BKA_JOIN(lineitem, part)*/ SELECT * FROM lineitem JOIN part ON l_partkey=p_partkey WHERE p_name LIKE '%green%';
+-------------+--------+
| BASELINE_ID | STATUS |
+-------------+--------+
| -399023558  | OK     |
+-------------+--------+

再度 BASELINE LIST を実行して、両方のプランがベースラインにあることを確認します (両方とも FIXED=0 であり、CBO がコストに基づいて選択することを意味します)。

mysql> BASELINE LIST;
+-------------+--------------------+-------------+--------------------------------------+-------+----------+
| BASELINE_ID | PARAMETERIZED_SQL  | PLAN_ID     | EXTERNALIZED_PLAN                    | FIXED | ACCEPTED |
+-------------+--------------------+-------------+--------------------------------------+-------+----------+
| -399023558  | SELECT * FROM ...  | -1024543942 | Gather > ParallelBKAJoin > ...       |     0 |        1 |
| -399023558  | SELECT * FROM ...  | -935671684  | Gather > ParallelHashJoin > ...      |     0 |        1 |
+-------------+--------------------+-------------+--------------------------------------+-------+----------+

ステップ 4：プランの固定 (任意)

CBO のコスト見積もりに関係なく、PolarDB-X 1.0 に常に BKA JOIN プランを使用させるには (例えば、バージョンアップグレード後のプランリグレッションを防ぐため)、BASELINE FIX を使用します。

mysql> BASELINE FIX SQL /*+TDDL:BKA_JOIN(lineitem, part)*/ SELECT * FROM lineitem JOIN part ON l_partkey=p_partkey WHERE p_name LIKE '%green%';
+-------------+--------+
| BASELINE_ID | STATUS |
+-------------+--------+
| -399023558  | OK     |
+-------------+--------+

BASELINE LIST を実行して、BKA JOIN プランの FIXED=1 を確認します。

mysql> BASELINE LIST\G
*************************** 1. row ***************************
      BASELINE_ID: -399023558
PARAMETERIZED_SQL: SELECT * FROM lineitem JOIN part ON l_partkey = p_partkey WHERE p_name LIKE ?
          PLAN_ID: -1024543942
EXTERNALIZED_PLAN:
Gather(parallel=true)
  ParallelBKAJoin(condition="l_partkey = p_partkey", type="inner")
    LogicalView(tables="[00-03].lineitem", ...)
    Gather(concurrent=true)
      LogicalView(tables="[00-03].part", ...)
            FIXED: 1
         ACCEPTED: 1
*************************** 2. row ***************************
      BASELINE_ID: -399023558
PARAMETERIZED_SQL: SELECT * FROM lineitem JOIN part ON l_partkey = p_partkey WHERE p_name LIKE ?
          PLAN_ID: -935671684
EXTERNALIZED_PLAN:
Gather(parallel=true)
  ParallelHashJoin(condition="l_partkey = p_partkey", type="inner")
    LogicalView(tables="[00-03].lineitem", ...)
    LogicalView(tables="[00-03].part", ...)
            FIXED: 0
         ACCEPTED: 1

FIXED=1 が設定されていると、ヒントがなくても、このクエリパターンのすべての実行で BKA JOIN プランが使用されます。

mysql> EXPLAIN SELECT * FROM lineitem JOIN part ON l_partkey=p_partkey WHERE p_name LIKE '%green%';

Gather(parallel=true)
  ParallelBKAJoin(condition="l_partkey = p_partkey", type="inner")
    LogicalView(tables="[00-03].lineitem", ...)
    Gather(concurrent=true)
      LogicalView(tables="[00-03].part", ...)
HitCache:true

固定されたプランを削除して CBO に再度選択させるには、BASELINE DELETE <baseline_id> でベースラインエントリを削除するか、BASELINE CLEAR <baseline_id> でメモリからクリアします。