プランのキャッシュ

通常、オプティマイザはクエリが実行されるたびに、その実行プランを選択します。実行時に最適化すると、オプティマイザは、現在のシステム状態、現在の選択性推定値、ホスト変数の値に基づく推定値に従ってプランを選択できます。頻繁に実行されるクエリの場合は、実行時に最適化することによる利点よりもクエリ最適化のコストの方が重要である場合があります。SQL Anywhere サーバは、これらの文を繰り返し最適化するコストを削減するために、次の文に関するプランのキャッシュを検討します。

ストアド・プロシージャ、ユーザ定義関数、トリガ内で実行されるすべての文。
最適化をバイパスするための条件を満たす SELECT 文、INSERT 文、UPDATE 文、DELETE 文。クエリ処理のフェーズを参照してください。

INSERT 文については、INSERT...VALUES 文だけがキャッシュの条件を満たします。INSERT...ON EXISTING 文は条件を満たしません。

UPDATE 文と DELETE 文については、WHERE 句が存在し、プライマリ・キーを使用してローを識別する探索条件を含んでいる必要があります。プランをキャッシュする場合は、他の探索条件は指定できません。また、UPDATE 文については、変数の代入を含む SET 句がある文はキャッシュの条件を満たしません。

1 つの接続でこのいずれかの文が複数回実行されたら、オプティマイザはホスト変数の値が不明なまま文の再利用可能なプランを構築します。選択性推定やセマンティック・クエリ変形にホスト変数の値を使用できないため、再利用可能なプランのコストは高くなる場合があります。再利用可能なプランの構造が、文が以前に実行されたときのプランと同じである場合、データベース・サーバは、そのプラン・キャッシュに再利用可能なプランを追加します。最適化を避けることによるコストの削減よりも、実行のたびに最適化することによる利点が勝る場合、実行プランはキャッシュされません。

文で参照されないマテリアライズド・ビューを実行プランで使用し、materialized_view_optimization オプションが Stale 以外に設定されている場合、実行プランはキャッシュされず、ストアド・プロシージャ、ユーザ定義関数、トリガの次回呼び出し時に文が最適化されます。

プラン・キャッシュは、アクセス・プランを実行したときに使われるデータ構造の接続ごとのキャッシュです。キャッシュされたプランの再利用には、キャッシュ内のプランを調べて初期状態にリセットする処理も含まれます。通常、これはすべてのクエリ処理フェーズを経由させて文を処理するよりも、はるかに高速です。使用頻度が低く、キャッシュの使用量が増えない場合、キャッシュされたプランはディスクに格納されます。オプティマイザはクエリを定期的に最適化し直して、キャッシュされたプランが依然として効率的であるかどうかを確認します。

キャッシュできるプランの最大数は、max_plans_cached オプションで指定します。デフォルトは 20 です。プランのキャッシュを無効にするには、このオプションを 0 に設定します。max_plans_cached オプション [データベース]を参照してください。

QueryCachedPlans 統計を使用して、現在キャッシュされているクエリ実行プラン数を表示できます。このプロパティを検索するために CONNECTION_PROPERTY 関数を使用すると、特定の接続についてキャッシュされているクエリ実行プラン数を表示できます。DB_PROPERTY 関数を使用すると、接続全体でキャッシュされている実行プランを数えることができます。このプロパティを QueryCachePages、QueryOptimized、QueryBypassed、QueryReused と組み合わせて使用すると、max_plans_cached オプションの最適な設定を決定するのに役立ちます。接続プロパティを参照してください。

データベース・プロパティまたは接続プロパティである QueryCachePages を使用すると、実行プランをキャッシュするために使用するページ数を決定できます。これらのページはテンポラリ・ファイル内の領域を占めますが、メモリに常駐するとはかぎりません。