SQL Server Join / where処理順序

Slow 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としてタグ付けされています。とにかく回答/コメントしてください

クエリの論理処理は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

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

しかしこれは論理的です：実際ではありません。。SQL Serverが実際にそれを実行する方法に関係なく、これらのセマンティクスはこの手紙を尊重します。「実際」はクエリオプティマイザー（QO）によって決定され、あなたが述べた中間のCartesion製品を避けます。

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

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

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

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

SQL Server 2000でこのトリックを使用して、レポートクエリのパフォーマンスを60倍向上させました。QOはバージョンごとに改善されるため、これらの作業をうまく行うことができます。

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

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

クエリオプティマイザーがこのクエリのプランを生成するときに考慮する可能性のある2つのオプションを評価しました。プランの選択に影響を与える主な要因は、関連するテーブルの統計とコストです関連候補プランでのオペレーターの選択に関連です。

例のような非常に単純な2つのテーブルの結合は、数百の異なる実行計画のいずれかで満足できます。オプティマイザーは、これらのプランのコストを比較して、クエリに回答する最適な方法を決定します。

それは時々間違ってしまい、改善されたインデックス作成、統計の更新の維持、ヒントの適用により、より良い選択を支援することができます。ごくまれに、FORCE ORDERヒントを使用して実行順序を強制したい場合がありますが、これは控えめに使用する必要があります。ナッツを割るのはハンマーです。通常、オプティマイザーは、より良い情報を提供することで、より良い計画を生成するようにからかわれます。