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

ご利用の PolarDB クラスターは、次のいずれかのバージョン要件を満たす必要があります。

• PolarDB for MySQL 8.0.1、リビジョンバージョン 8.0.1.1.33 以降。

• PolarDB for MySQL 8.0.2、リビジョンバージョン 8.0.2.2.12 以降。

SQL ステートメントの実行計画は、SQL Sharing モジュールに格納されます。次の SQL ステートメントを実行して、INFORMATION_SCHEMA.SQL_SHARING テーブルからプランキャッシュ内のキャッシュ情報をクエリできます。

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 に設定します。

   自動プランキャッシュモードは、次の 2 つの方法のいずれかで設定できます。

   • 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 リストの長さは 20 でした。パフォーマンスは、プリペアドステートメント (PS) プロトコルと非 PS プロトコルの両方で、loose_plan_cache_type パラメーターを OFF、AUTO、および ENFORCE に設定してテストされました。テスト結果は次のとおりです。

• PS プロトコルでのパフォーマンス テスト結果：

• 非 PS プロトコルでのパフォーマンス テスト結果：

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