0

クエリ プランは、ビューと通常の SQL の両方のプラン キャッシュに格納されます。

ここから

わかった。

もう一度:それはどのように私を助けますか?

クエリを実行Query plansした場合でも、クエリを実行すると、テーブル全体 + 集計 + .... がスキャンされます。cache

明日実行すると、テーブル全体と集計が再度スキャンされます....

このような状況はあり得ません: "ああ!!! キャッシュにデータがあるので、そこから取得します.... ...(テーブルが変更された可能性があるため...)

では、真のメリットはどこにあるのでしょうか?

何かが足りないようです。

ありがとうございました。

4

4 に答える 4

3

次のようなクエリがあるとします。

SELECT *
FROM 
    A 
    INNER JOIN B ON -- omitted
    INNER JOIN C ON -- omitted
    -- omitted
    INNER JOIN Q ON -- omitted

ただし、多くのテーブルがあります。明らかに、これらの結合が実行される順序はパフォーマンスに影響します。また、テーブルの統計を考慮して最適な順序を決定するのにも時間がかかります。

クエリ プランをキャッシュすることで、最適な順序を決定するコストを1 回だけ支払うことができます。その後クエリが実行されるたびに、最初に を取得Kし、それを に結合しE、次に に結合するなどの手順を実行することが既にわかっていHます。

もちろん、これはデータ統計の大幅な変更が計画を無効にすることを意味しますが、何かをキャッシュすることには常にトレードオフが伴います。

クエリ計画の方法と理由について詳しく学習するのに役立つリソースは、SQL コーチです。まずTHE類推から始めてください。

于 2012-04-04T16:28:05.347 に答える
2

答えは、毎回クエリ プランをコンパイルするコストを回避するために、クエリ プランがキャッシュされることです。クエリ (または同じプランを使用できる別のクエリ) を 2 回目に実行するときは、コンパイル プロセスを最初からやり直す必要はありません。キャッシュからプランをプルするだけです。

于 2012-04-04T16:26:38.793 に答える
1

簡単に言うと、実行プランはクエリがどのように実行されるかの説明であり、クエリに含まれる実際のデータではありません (したがって、クエリを再実行するときに実行プランを何度も適用できます)。

アナロジーは、実行計画がレシピに似ていると言うことです-それはデータ/食事自体ではなく、データを取得/食事を作る方法です.

改善点は、DB エンジンがクエリの実行計画を作成するのに時間がかかることです。そのため、キャッシュされている場合、次に同じクエリを実行するときにそのオーバーヘッドは必要ありません。

于 2012-04-04T16:27:34.460 に答える
0

クエリを SQL に送信すると、いくつかの手順を経て結果が表示されます。主なものは、解析、algebrizer、クエリ オプティマイザーです。

クエリオプティマイザーは、実行プランを作成するか、キャッシュから選択する責任があります。私が理解しているように、プランを作成するプロセスは非常にコストがかかるため、再利用できるとよいでしょう。

主なポイントは、実行計画にはデータ自体が含まれておらず、BD からデータを取得する方法のみが含まれているということです。したがって、プランが「定義」されると、ストレージ エンジンに渡され、データの取得に使用されます。

于 2012-04-04T16:30:49.773 に答える