sql - データベースの実行計画

Question

質問1：

クエリを実行すると、クエリを実行するたびに実行プランが変更されますか？

はいの場合、パフォーマンスに影響はありますか？

いいえの場合、テーブル内の何かを変更する場合、つまりインデックスを追加する場合、データベースは、実行プランを変更して実行を高速化するために使用できるものがあることをどのように認識しますか？

質問2：

ただし、結合クエリの実行中の一般的な実行順序は何ですか。特に、結合が多い場合（外部、内部、自然、外部が多い場合）はどうでしょうか。

Answer 1

• SQL Serverについて正確に言うと、次のようになります。

キャッシュには最大で2つのプランがあります（1つは並列、もう1つは非並列）。次に、プランはユーザーごとの実行コンテキストで使用されます。ここに私の答えの詳細情報

• JOINの順序は、ほとんどすべての場合に関係ありません

SQLは宣言型です。これは、エンジンに必要なものを伝え、オプティマイザーが最適な計画を作成することを意味します（理由の範囲内で、最適な計画を作成するのに2週間かかる場合があります）。これが、同じ答えを得るためにクエリをさまざまな方法で書き直すことができる理由です。

RDBMSに関する他のルールと同様に、例外があります。複雑なクエリの場合、オプティマイザーはすべての順列を通過するわけではないため、JOINの順序が重要になる可能性があります。オプティマイザーが十分であると判断するタイミングによって異なります...

Answer 2

（ここでSQL Serverを想定すると、指定しませんでした...）

実行プランはキャッシュされ、クエリをパラメータ化する程度まで再利用できます。

基になるテーブルまたはインデックスを変更すると、SQL Serverは、これらのものの変更日とキャッシュされた実行プランを認識し、新しい条件についてクエリを再評価できます。統計が更新されるときも同じです...テーブル/インデックスの設計だけでなく、実際のデータが計画を左右する場合があります。

Answer 3

結合は、内部と外部に基づく順序ではなく、オプティマイザーがクエリを最も迅速に実行する結果になると考えていることに基づいて行われます。詳細はデータベースによって異なります。ただし、基本的に、クエリオプティマイザはインデックスの使用を最適化しようとします。

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

select a.foo, b.bar
from a
join b on b.b_id=a.b_id
where a.some_number=42;

ここで、b.b_idに一意のインデックスがあり、a.some_numberにはインデックスがないとします。

クエリオプティマイザには2つの選択肢があります。bでフルファイルシーケンシャル読み取りを実行し、b_idとsome_number=42で一致するものを探して各bに対してフルファイルシーケンシャル読み取りを実行します。それはa^bレコードを読み取ります。または、some_number = 42を探してフルファイルシーケンシャル読み取りを実行し、次に各aについて、インデックスを使用して、b_idが一致するbからレコードをすばやく見つけることができます。つまり、a*2レコードを読み取ります。明らかに、2番目の計画の方がはるかに優れているので、それが選択されます。

テーブルを追加すると、計算はより複雑になりますが、原則は同じです。他のテーブルで見つかった値を使用してインデックスをすばやく読み取る結果となる結合は、他のテーブルが読み取られた後、後で実行されます。何があっても、または他のレコードからの値ではなく定数に基づいて読み取られる場所に関係なく、順次読み取る必要があるテーブルは、通常、最初に読み取られます。