PolarDB:自動プランキャッシュ

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

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

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

INFORMATION_SCHEMA.SQL_SHARING テーブルから次の SQL 文を実行して、プランキャッシュの情報をクエリできます。

SELECT TYPE, REF_BY, SQL_ID, SCHEMA_NAME, DIGEST_TEXT, PLAN_ID, PLAN, PLAN_EXTRA, EXTRA FROM INFORMATION_SCHEMA.SQL_SHARING WHERE json_contains(REF_BY, '"PLAN_CACHE"') or 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=demand;

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 INFORMATION_SCHEMA.SQL_SHARING WHERE json_contains(REF_BY, '"PLAN_CACHE"') or json_contains(REF_BY, '"PLAN_CACHE(DEMAND)"')\G

   結果例：

   *************************** 1. row ***************************
          TYPE: SQL
        REF_BY: ["PLAN_CACHE(DEMAND)"]
        SQL_ID: 9jrvksr3wjux6
   SCHEMA_NAME: test
   DIGEST_TEXT: SELECT * FROM `t_for_plan` WHERE `c1` > ? AND `c1` < ?
       PLAN_ID: NULL
          PLAN: NULL
    PLAN_EXTRA: NULL
         EXTRA: {"TRACE_ROW_ID":1}
   *************************** 2. row ***************************
          TYPE: PLAN
        REF_BY: ["PLAN_CACHE"]
        SQL_ID: 9jrvksr3wjux6
   SCHEMA_NAME: test
   DIGEST_TEXT: NULL
       PLAN_ID: 08xftakma6pm6
          PLAN: /*+ 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 個のテーブルが作成されます。各テーブルには 400 万行のデータが格納されます。テストで使用される SQL 文は、SELECT id FROM sbtestN WHERE k IN(...) です。IN LIST の長さは 20 です。 loose_plan_cache_type パラメーターが OFF、AUTO、および ENFORCE に設定されている場合のパフォーマンスを、PS プロトコルと非 PS プロトコルの両方でテストします。テスト結果：

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

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

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