web-dev-qa-db-ja.com

SQL Serverの結合/場所の処理順序

遅いSQLクエリ、最適化の方法がわからない を読んだ後、クエリの一般的なパフォーマンスについて考えました。確かに、クエリを少し高速にするために、結合（この質問の内部結合）の前に、最初のテーブル（他のテーブルが結合されている場合）の結果をできるだけ小さくする必要があります。

例、これは：

SELECT *
FROM   ( SELECT * FROM table1 WHERE col = @val ) t
INNER JOIN table2 ON col = col2

次より優れている/速い

SELECT *
FROM table1
INNER JOIN table2 ON col = col2
WHERE table1.col = @val

私の理論は次のとおりです（これは正しい実装ではない可能性があります。私が読んだSQL Server 2008内部の本（MSFT Press）から思い出そうとしています）：

  1. クエリプロセッサは最初に左側のテーブル（table1）を取得します
  2. 2番目のテーブル（table2）を結合し、必要な行を除外する前にデカルト積を形成します（該当する場合）。
  3. 次に、最後にSEELCTステートメントを使用してWHERE、ORDER BY、GROUP BY、HAVING句を実行します。

したがって、上記のステートメント＃1でテーブルが小さい場合、SQLエンジンはデカルト積を形成するときに行う作業が少なくなります。次に、whereステートメントに到達すると、メモリ内でフィルタリングする元になる結果セットが少なくなります。

私はそれが非現実的であるマークから遠く離れている可能性があります。私が言ったように、それは理論です。

あなたの考え？

注：私はこの質問について考えたばかりで、まだ自分でテストを実行する機会がありませんでした。

注2：MySqlの実装などについて何も知らないため、SQL Serverとしてタグ付けされていますとにかく答え/コメントしてください

sql-serverperformancejoin
18
Stuart Blackler

クエリの論理処理はオンです [〜＃〜] msdn [〜＃〜] （Microsoft SQL Serverチームによって記述され、サードパーティではありません）

1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. WITH CUBE or WITH ROLLUP
7. HAVING
8. SELECT
9. DISTINCT
10. ORDER BY
11. TOP

派生テーブルがこれに続き、外部クエリが再びそれを実行するなど

これはlogicalですが、actualではありません。 SQL Serverが実際にどのように実行するかに関係なく、これらのセマンティクスは尊重されます文字通り。 「実際の」は、クエリオプティマイザー（QO）によって決定され、あなたが述べた中間のCartesion製品を避けます。

SQLは宣言型であることに言及する価値があります。手続き型/命令型プログラミング（Java、.net）の場合と同じように、「どのように」ではなく「何を」と言います。そのため、「これはその前に発生する」というのは多くの場合間違っています（たとえば、短絡またはL-to-R WHERE順序の仮定）

上記のケースでは、QOは単純なクエリなので、どのように構造化されていても同じ計画を生成します。

ただし、QOはコストベースであり、複雑なクエリの場合、理想的なプランを生成するのに2週間かかる場合があります。だから、それは実際には不十分です。

したがって、最初のケースは、2つのクエリの論理処理順序が異なるため、オプティマイザがより良い計画を見つけるのに役立ちます。しかし、そうではないかもしれません。

SQL Server 2000でこのトリックを使用して、レポートクエリのパフォーマンスを60倍高速化しました。 QOによってバージョンがバージョンごとに改善されるため、これらのことをうまく処理できるようになります。

そしてあなたが言及した本：それについていくつかの論争があります
SOと後続のリンクを参照： https://stackoverflow.com/q/3270338/27535

16
gbn

SQLクエリは本質的に手続き型ではなく、結合演算子の上から下への処理はありません。クエリ例でのテーブルの順序は、 実行プラン には影響しません。これらは論理的に同等であり、まったく同じプランを生成するためです。

query optimiser がこのクエリのプランを生成するときに検討する可能性がある2つのオプションをある程度評価しました。プランの選択に影響を与える主な要因は、関係するテーブルの statistics と、候補プランの演算子の選択に関連付けられた costs です。

あなたの例のような非常に単純な2つのテーブルの結合は、何百もの異なる実行プランのどれでも満足できます。オプティマイザは、これらの計画のコストを比較することにより、クエリに答える最良の方法を決定します。

それは時々それを誤解し、改善されたインデックス付け、統計の更新の維持、ヒントの適用を通じて、より良い選択をするのを助けることができます。ごくまれに、FORCE ORDERヒントを使用して実行順序を強制したい場合がありますが、これは慎重に使用する必要があります。それはより良い情報を与えることによってより良い計画を生成するためにオプティマイザは通常いじめられることができます。

6
Mark Storey-Smith