sql - SQLServer2005-内部結合の順序

Question

Where句に3つの内部結合ステートメントを含むクエリがあります。クエリの実行には約2分かかります。2つの内部結合の順序を単純に変更すると、パフォーマンスは40秒に低下します。

内部結合の順序を変更する以外に何もしないと、クエリのパフォーマンスに劇的な影響を与えることができますか？私はオプティマイザーがこれをすべて理解すると思っていたでしょう。

Answer 1

SQLは宣言型です。つまり、JOINの順序は重要ではありません。

ただし、実際には、オプティマイザーがすべてのオプションを調査しない場合（理論的には数か月かかる可能性があります）、複雑なクエリである場合は可能です。

もう1つのオプションは、並べ替えて異なる結果が得られる場合はクエリが大きく異なることですが、これは通常、外部結合を使用する場合です。

また、ON句を指定する方法でもあります。FROM句を並べ替える場合は変更する必要があります。古い（そして悪い）JOIN-in-the-WHERE句を使用している場合を除きます。

最後に、懸念がある場合は、括弧を使用して評価順序を変更し、意図を明確にすることができます。たとえば、最初に大きなテーブルでフィルタリングして、派生テーブルを生成します。

Answer 2

結合の順序を変更することにより、SQL Serverはクエリに対して異なる実行プランを考え出すためです（結合に基づいてテーブルをフィルタリングする方法が変更される可能性があります）。

この場合、いくつかの大きなテーブルがあると思います...そのうちの1つがフィルタリングの大部分を実行します。

1つのクエリでは、結合によっていくつかの大きなテーブルが結合され、最後にレコードがフィルタリングされます。

もう1つは、最初のテーブルをデータのはるかに小さいサブセットにフィルタリングし、残りのテーブルを結合します。その最初のテーブルは他の大きなレコードセットを結合する前にフィルタリングされるため、パフォーマンスは大幅に向上します。より良い。

いつでも確認できますが、[クエリプランの表示]オプションを有効にしてクエリを実行し、2つの異なる結合順序のクエリプランを確認できます。

Answer 3

それも十分賢いと思いましたが、明示的にリストした順序で結合を実行していることは明らかです...なぜそれがパフォーマンスに影響するのかについては、最初の結合で中間結果セットのみが生成される場合1つの順序付けスキームで100レコードの場合、2番目の結合はその100レコードセットから3番目のテーブルになります。もう一方の結合を最初に配置すると、100万レコードの最初の中間結果セットが生成される場合、2番目の結合は100万行の結果セットから3番目のテーブルになります...