それらはすべて機能的に同等です。 WHERE句とJOIN条件を分離しても、完全にINNER結合で作業している場合は結果が変わりません（OUTER結合で問題になる可能性があります）。さらに、これらはすべて、まったく同じクエリプランで機能する必要があります（実質的にパフォーマンスの違いはありません）。アイテムを含める順序は重要ではありません 。クエリエンジンは、クエリの機能仕様に最適であると判断したため、自由に最適化できます。注文に関して特定の行動を特定したとしても、それを当てにするべきではありません。この仕様では、明日のパッチでこの領域の今日の動作を変更できます。注意：SQLの要点は、セットベースで宣言型である必要があります。 ：データベースに何を伝える 方法ではなく、実行したい あなたはそれをしたいのです。
正確さとパフォーマンスが邪魔にならないようになったので、プログラマーの生産性やコードの可読性/保守性などのスタイルの問題に取り掛かります。その点で、そのリストのオプション＃4ははるかに 最良の選択であり、特により複雑なクエリを開始する場合は、＃3が次に最適です。 A,Bは使用しないでください もう構文; SQL標準の1992バージョン以降は廃止されています。常に完全なINNER JOINを書き出す （またはLEFT JOIN /RIGHT JOIN / CROSS JOIN など）。
とはいえ、順序はパフォーマンスには関係ありませんが（または、少なくともそうすべきです）、SQLを記述しているときに、順序を決定するアプローチで規則を使用すると便利です。これは、後でデバッグやトラブルシューティングを行うときに、エラーや誤った仮定を特定するのに役立ちます。私が従おうとしているこの一般的なガイドは、順序が重要であるかのように動作することです。次に、そのことを念頭に置いて、データベースがクエリを実行するために必要なメモリのワーキングセットを可能な限り小さく保つようにしてください。最初に小さいテーブルから始めて、次に大きいテーブルに結合します。テーブルサイズを検討するときは、インデックスと一致するWHERE句の条件を考慮してください。選択肢がある場合は、外部結合よりも内部結合を優先します。最初にインデックス（特にプライマリ/クラスター化キー）を優先する結合条件をリストし、次に結合に関する他の条件をリストします。