OceanBaseデータベースは、複雑な書き換えルールとプラン生成アルゴリズムにより強力な最適化機能を提供しますが、これによりプラン生成にかかる時間も増加します。例えば、極端なTPシナリオでは、主キーによる単一ポイント・ルックアップ・クエリのプラン生成に1msかかる場合がありますが、実際の実行にはわずか0.5msしか必要ありません。各SQL文ごとにプランを再生成すると、時間の大部分がプラン生成段階に集中してしまいます。このため、OceanBaseは**プランキャッシュ（Plan Cache）**メカニズムを導入し、同一SQL文で実行プランを共有することで、応答時間を大幅に短縮します。
タイプのシナリオ
HTAPビジネスにおいて、特定のSQL文の実行時間が計画生成時間を大幅に上回る場合（例えば、実行時間が10ms、計画生成時間が1ms）、かつ実行時間/生成時間 = 10（デフォルトのしきい値5を超過）となると、連続して5回発生した後、システムはそのSQL文の計画キャッシュを自動的に無効化し、実行パフォーマンスを最適化します。
プランキャッシュメカニズム
主要なプロセス
SQLパラメータ化：
- OceanBaseデータベースがSQLリクエストを受信すると、まず
fast parserモジュールを使用して、SQLテキスト内の定数パラメータをワイルドカード?に置き換えます。 - 例：
SELECT * FROM t1 WHERE c1 = 1はSELECT * FROM t1 WHERE c1 = ?に置き換えられます。
- OceanBaseデータベースがSQLリクエストを受信すると、まず
キャッシュヒットチェック：
- パラメータ化されたSQLにキャッシュプランが存在するかどうかを確認します。
- キャッシュヒットした場合：既存のプランを直接実行します。
- キャッシュヒットしない場合：新しいプランを生成してキャッシュに格納します。
パフォーマンスの利点：
- キャッシュからプランを取得する時間は、通常、再生成よりも1桁小さい（例えば、1msから0.1msに短縮）。
アダプティブ計画キャッシュ
HTAPハイブリッドワークロードシナリオにおいて：
- TPシナリオ：計画キャッシュを有効にすることで、重複する計画の再生成にかかる時間を短縮します。デフォルトでは有効です。
- APシナリオ：計画キャッシュを無効にすることでパフォーマンスが向上します（より最適な計画が生成されますが、時間はかかります）。
- HTAPハイブリッドワークロードのビジネスシナリオ：Plan Cacheを無効にすると、AP寄りのSQLのパフォーマンスは向上しますが、TP寄りのSQLにも大きな影響を与えます。
OceanBase V4.3.5 BP2バージョン では、アダプティブ計画キャッシュ が新たに追加されました。これにより、SQLの特性に基づいて動的に計画キャッシュを有効にするかどうかを決定し、両方のシナリオのパフォーマンスをバランスさせることが可能になります。
主要な構成パラメータ
OceanBaseデータベースV4.3.5 BP2バージョンでは、適応型計画キャッシュに関する新しい構成パラメータが追加されました：
enable_adaptive_plan_cache：テナントレベルの構成パラメータで、テナントでの計画キャッシュの適応機能を有効にするかどうかを制御します。詳細については、enable_adaptive_plan_cacheを参照してください。_pc_adaptive_min_exec_time_threshold：テナントレベルの非表示構成パラメータで、適応型計画キャッシュを有効にするための最小実行時間のしきい値を制御します。適応型計画キャッシュ機能が有効な場合、実行時間がこのしきい値を超えるSQL文に対してのみ適応型計画キャッシュが有効になります。プロパティの説明は以下のとおりです：プロパティ 説明 パラメータタイプ TIME デフォルト値 1s 値の範囲 [0, +∞] 変更は可能か はい。 ALTER SYSTEM SETステートメントを使用してこの構成パラメータの値を変更できます。例：ALTER SYSTEM SET _pc_adaptive_min_exec_time_threshold = '2s';。説明
Oracleモードでは、構文上、構成パラメータに二重引用符を付ける必要があります。
OBServerノードの再起動が必要か 不要です。設定は即時に反映されます。 _pc_adaptive_effectiveness_ratio_threshold：テナントレベルの非表示構成パラメータで、適応型計画キャッシュを有効にするための最小比率のしきい値を制御します。適応型計画キャッシュ機能が有効な場合、計画の実行時間／計画の生成時間がこのしきい値以上である場合にのみ適応型計画キャッシュが有効になります。プロパティの説明は以下のとおりです：プロパティ 説明 パラメータタイプ INT デフォルト値 5 値の範囲 [0, +∞] 変更は可能か はい。 ALTER SYSTEM SETステートメントを使用してこの構成パラメータの値を変更できます。例：ALTER SYSTEM SET _pc_adaptive_effectiveness_ratio_threshold = 6;。説明
Oracleモードでは、構文上隠れた構成パラメータには二重引用符を付ける必要があります。
OBServerノードの再起動が必要か 不要です。設定は即時に反映されます。 _force_enable_plan_tracing：テナントレベルの非表示構成パラメータで、計画キャッシュが無効な場合に計画トレースを有効にするかどうかを制御します。プロパティの説明は以下のとおりです：プロパティ 説明 パラメータタイプ BOOL デフォルト値 TRUE。計画キャッシュを無効にした場合に計画追跡を有効にすることを示します。 値の範囲 - TRUE
- FALSE
変更は可能か はい。 ALTER SYSTEM SETステートメントを使用してこの構成パラメータの値を変更できます。例：ALTER SYSTEM SET _force_enable_plan_tracing = FALSE;。説明
Oracleモードでは、構文上隠れている構成パラメータには二重引用符を付ける必要があります。
OBServerノードの再起動が必要か 不要です。設定は即時に反映されます。
アダプティブなキャッシュ無効化条件
アダプティブ機能が有効になっている場合、次のすべての条件を満たすSQL文について、システムはその計画キャッシュを無効化します。
- 実行時間しきい値：
- SQL実行時間 ≥
_pc_adaptive_min_exec_time_threshold(デフォルトは1秒)。
- SQL実行時間 ≥
- 効率比しきい値：
実行時間 / 計画生成時間 ≥ _pc_adaptive_effectiveness_ratio_threshold(デフォルトは5)。
- 連続トリガー回数：
- 連続5回の実行で上記の条件を満たす。
キャッシュされた実行計画の照会と管理
OceanBaseデータベースは、キャッシュされた実行計画を照会および管理するために、以下の2つのシステムビューを提供しています：
GV$OB_PLAN_CACHE_PLAN_STAT：各実行計画の計画キャッシュ内での実際の計画形態を記録します。指定された（IPアドレス、ポート、テナントID、計画ID）の4元組を使用することで、特定の計画のツリー形式の計画形態を照会できます。このビューを使用することで、サーバー上でCPUを多く消費するSQLを特定し、チューニングを行うことでデータベースのパフォーマンスを最適化できます。GV$OB_PLAN_CACHE_PLAN_EXPLAIN：このビューは、各実行計画の計画キャッシュ内での実際の計画形態を記録します。指定された（IPアドレス、ポート、テナントID、計画ID）の4元組を使用することで、特定の計画のツリー形式の計画形態を照会できます。
プランの照会例
以下のSQLは、GV$OB_PLAN_CACHE_PLAN_EXPLAINを使用して特定の計画の形態を取得する方法を示しています：
SELECT plan_line_id, operator, name, rows, cost
FROM oceanbase.gv$ob_plan_cache_plan_explain
WHERE svr_ip = 'xx.xx.xx.xx'
AND svr_port = 30042
AND tenant_id = 1001
AND plan_id = 248;
実行結果：
+--------------+------------------------+--------------+---------+----------+
| plan_line_id | operator | name | rows | cost |
+--------------+------------------------+--------------+---------+----------+
| 0 | PHY_SORT | NULL | 6 | 16522 |
| 1 | PHY_HASH_GROUP_BY | NULL | 6 | 16506 |
| 2 | PHY_TABLE_SCAN | lineitem | 11473 | 6597 |
+--------------+------------------------+--------------+---------+----------+
この結果は、OceanBaseデータベースで直接explainを実行した結果と非常に似ていることがわかります。注意すべき点として、ここで照会される計画は対応するSQLが初めて実行された際のパラメータに基づいて生成されているため、同一のSQLに対してexplainを実行した場合でも、その結果とGV$OB_PLAN_CACHE_PLAN_EXPLAINで照会される結果が一致しない場合があるということです。このような場合、計画キャッシュのバッドケースに遭遇している可能性があり、計画バインディングを通じて安定した計画を固定する必要があるかどうか検討することができます。
関連ドキュメント
クエリキャッシュの実行計画ビューに関するドキュメントは以下のとおりです：