すべての SQL ベースの RDBMS' (10 年前までのバージョン):
ストレート ジョイン クエリ (ヒント ディレクティブなし) でのテーブルの順序は、最適なパフォーマンスとメモリ管理に違いをもたらしますか? 最後の結合は最大のテーブルにする必要があると聞きました。DB のクエリ オプティマイザはこのシナリオをどのように処理しますか?
すべての SQL ベースの RDBMS' (10 年前までのバージョン):
ストレート ジョイン クエリ (ヒント ディレクティブなし) でのテーブルの順序は、最適なパフォーマンスとメモリ管理に違いをもたらしますか? 最後の結合は最大のテーブルにする必要があると聞きました。DB のクエリ オプティマイザはこのシナリオをどのように処理しますか?
あなたの質問への回答 - はい、テーブルの順序が結合に違いをもたらします。
実行計画についてオプティマイザに知らせることもできます。
ORDERED ヒントにより、Oracle は FROM 句に表示される順序でテーブルを結合します。
たとえば、次のステートメントはテーブル TAB1 をテーブル TAB2 に結合し、その結果をテーブル TAB3 に結合します。
SELECT /*+ ORDERED */ TAB1.COL1, TAB2.COL2, TAB3.COL3
FROM TAB1, TAB2, TAB3
WHERE TAB1.COL1 = TAB2.COL1
AND TAB2.COL1 = TAB3.COL1;
結合を実行する SQL ステートメントから ORDERED ヒントを省略すると、オプティマイザーがテーブルを結合する順序を選択します。各テーブルから選択された行数についてオプティマイザが把握していないことがわかっている場合は、ORDERED ヒントを使用して結合順序を指定することをお勧めします。このような情報により、オプティマイザーよりも適切に内部テーブルと外部テーブルを選択できます。
通常、テーブルを分析すると、オプティマイザは効率的なスター プランを選択します。ヒントを使用して計画を改善することもできます。最も正確な方法は、大きなテーブルを最後にして、FROM 句内のテーブルをインデックス内のキーの順に並べることです。次に、次のヒントを使用します。
/*+ ORDERED USE_NL(FACTS) INDEX(FACTS FACT_CONCAT) */
ただ主題にもっと追加するために...はいといいえ、依存します。それが私の答えです。これは、使用しているRDBMS(MySQL、MSSQL Server、Oracle、DB2 ...)、結合のタイプ、テーブルのサイズ(別名、行数)、インデックスなど、多くの要因によって異なります。
前の回答は「はい」と「いいえ」で、クエリにヒントを使用することをアピールしています。しかし、あなたの質問は:
結合ステートメント内のテーブルの順序に違いはありますか...
私の意見では、クエリオプティマイザに好みの順序を使用させるため、クエリヒントの使用は省略されます。
したがって、質問に対する最初のコメントに投稿された回答を再利用すると、@ Mark Brackettは、クエリオプティマイザが現在のクエリに対して最も効率的な実行プランを使用するため、結合の再配置(クエリヒントなし)はパフォーマンスに影響しないことを正しく指摘します。 。おそらくそれは最も効率的ではないので、ヒントを使用して、結合で必要な順序を使用するように強制し、クエリの実行プランを変更することができます。
次のリンクでこのテーマに関する詳細な議論: JOIN句で順序は重要ですか? 結合方法を最適化する
いいえ。
とにかく、Informixに関する限り。オプティマイザーは、テーブルを処理する順序を自分で決定しますFROM
。句に表示される順序は重要ではありません。デフォルトの動作をオーバーライドすることを選択しない限り。
クエリ オプティマイザーへのヒントを使用して、句で+ORDERED
提示されている順序でテーブルを強制的に結合できます。つまり、次のようになります。WHERE
SELECT --+ORDERED
x.col1, y.col2, z.col3
FROM z, y, x
WHERE ...
これにより、オプティマイザは z をスキャンし、y に結合し、x に結合します。これにより中間デカルト積が作成される場合でも同様です。したがって、注意して使用する必要があります。
注意: この回答は、質問に複数の RDBMS テクノロジではなく、Informix のみのタグが付けられたときに書かれました。