PolarDB:自動計画キャッシュ

PolarDBクラスターでは、次のいずれかのバージョンを使用します。

• リビジョンバージョンが8.0.1.1.33以降のPolarDB for MySQL 8.0.1のクラスター。

• リビジョンバージョンが8.0.2.2.12以降のPolarDB for MySQL 8.0.2のクラスター。

SQL文の実行計画は、SQL共有モジュールに格納されます。 次のSQL文を実行して、INFORMATION_SCHEMA.SQL_SHARINGテーブルからプランキャッシュの情報を照会できます。

SELECT TYPE、REF_BY、SQL_ID、SCHEMA_NAME、DIGEST_TEXT、PLAN_ID、PLAN、PLAN_EXTRA、EXTRA FROM json_contains(REF_BY、'"PLAN_CACHE"') またはjson_contains(REF_BY、'"PLAN_CACHE(DEMAND)"')\G

例

1. データを準備します。

   CREATE TABLE t_for_plan AS WITH RECURSIVE t(c1, c2, c3) AS (SELECT 1, 1, 1 UNION ALL SELECT c1 + 1, c1 % 50, c1 % 200 FROM t WHERE c1 < 1000) SELECT c1, c2, c3 FROM t;
   CREATE INDEX i_c1_c2 on t_for_plan(c1, c2); 

2. 自動計画キャッシュモードをDEMANDに設定します。

   次のいずれかの方法を使用して、自動計画キャッシュモードを設定できます。

   • PolarDB コンソールの [パラメーター] ページで、loose_plan_cache_typeパラメーターを [DEMAND] に設定します。 切断してから、データベースに再接続します。

   • 現在のデータベース接続を維持し、次のステートメントを実行して、現在のセッションのplan_cache_typeパラメーターをDEMANDに設定します。

     SET plan_cache_type=需要;

3. 次のステートメントを実行して、指定したSQLステートメントの実行プランをプランキャッシュにキャッシュします。

   CALL dbms_sql.add_plan_cache("test" 、"SELECT * FROM t_for_plan WHERE c1 > 1 AND c1 < 10");

4. クエリ文を実行します。

   SELECT * FROM t_for_plan WHERE c1 > 1 AND c1 < 10;

5. プランキャッシュの情報を照会します。

   SELECT TYPE、REF_BY、SQL_ID、SCHEMA_NAME、DIGEST_TEXT、PLAN_ID、PLAN、PLAN_EXTRA、EXTRA FROM json_contains(REF_BY、'"PLAN_CACHE"') またはjson_contains(REF_BY、'"PLAN_CACHE(DEMAND)"')\G

   サンプル結果:

   *************************** 1。 行 ***************************
          タイプ: SQL
        REF_BY: ["PLAN_CACHE(DEMAND)"]
        SQL_ID: 9jrvksr3wjux6
   SCHEMA_NAME: テスト
   DIGEST_TEXT: SELECT * FROM 't_for_plan 'WHERE 'c1' > ? そして 'c1' < ?
       PLAN_ID: NULL
          プラン: NULL
    PLAN_EXTRA: NULL
         追加: {"TRACE_ROW_ID":1}
   *************************** 2. 行 ***************************
          タイプ: 計画
        REF_BY: ["PLAN_CACHE"]
        SQL_ID: 9jrvksr3wjux6
   SCHEMA_NAME: テスト
   DIGEST_TEXT: NULL
       プランID: 08xftakma6pm6
          プラン: /* + INDEX('t_for_plan '@ 'select#1' 'i_c1_c2 ') * /
    PLAN_EXTRA: {"access_type":["'t_for_plan ':range"]}
         EXTRA: {"PLAN_CACHE_INFO":{"tables":['test'.'t_for_plan '] 、"versions":[0] 、"hits": 0}} 

   EXTRAフィールドのPLAN_CACHE_INFO項目には、参照されているテーブル、参照されているテーブルのバージョン、および実行プランのヒット数が表示されます。

ストレステストは、8コアと32 GBのメモリを使用するクラスターに対して実行されます。 25のテーブルがデータベースに作成されます。 各テーブルは4百万行のデータを格納する。 テストで使用されるSQL文は、SELECT id FROM sbtestN WHERE k in (...) です。 IN LISTの長さは20である。 パフォーマンスは、PSプロトコルと非PSプロトコルの両方で、loose_plan_cache_typeパラメーターがOFF、AUTO、およびENFORCEに設定されている場合にテストされます。 テスト結果：

• PSプロトコルのパフォーマンステストの結果を次の図に示します。

• 次の図は、非PSプロトコルのパフォーマンステストの結果を示しています。

テスト結果は、自動計画キャッシュ機能がPSプロトコルと非PSプロトコルの両方で50% 以上パフォーマンスを向上できることを示しています。