JOINまたはWHERE内の条件

JOIN句とWHERE句に条件を置くことの間に違い（パフォーマンス、ベストプラクティスなど）はありますか？

例えば...

-- Condition in JOIN
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND CUS.FirstName = 'John'

-- Condition in WHERE
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE CUS.FirstName = 'John'

あなたはどちらを好みますか（そしておそらくなぜですか）？

リレーショナル代数を使用すると、WHERE句との述語を交換できますINNER JOIN。そのため、句を含むINNER JOINクエリでもWHERE、オプティマイザによって述語を並べ替えることができるため、処理中に述語を除外できJOINます。

できるだけ読みやすい方法でクエリを記述することをお勧めします。

これには、INNER JOIN比較的「不完全」なものをWHERE作成し、フィルター基準のリストをより簡単に保守できるようにするために、いくつかの基準を単純に含めることが含まれる場合があります。

たとえば、次の代わりに：

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

書く：

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

しかし、それはもちろん異なります。

内部結合の場合、私は実際には違いに気づきませんでした（ただし、すべてのパフォーマンスチューニングと同様に、自分の条件下でデータベースと照合する必要があります）。

ただし、条件をどこに置くかは、左結合または右結合を使用している場合に大きく異なります。たとえば、次の2つのクエリを考えてみます。

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderDate >'20090515'

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND ORD.OrderDate >'20090515'

最初のものは、2009年5月15日より後に日付が付けられたレコードのみを提供するため、左結合が内部結合に変換されます。2番目は、これらのレコードと、注文のない顧客を示します。結果セットは、条件をどこに置くかによって大きく異なります。（例としてのみ使用する場合は、*を選択してください。もちろん、実稼働コードでは使用しないでください。）これの例外は、1つのテーブルのレコードのみを表示し、他のテーブルのレコードは表示しない場合です。次に、結合ではなく条件にwhere句を使用します。

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderID is null

ほとんどのRDBMS製品は、両方のクエリを同じように最適化します。Peter GulutzanとTrudy Pelzerによる「SQLパフォーマンスチューニング」では、RDBMSの複数のブランドをテストしましたが、パフォーマンスに違いはありませんでした。

結合条件をクエリ制限条件とは別にしたい。

使用しているOUTER JOIN場合は、結合句に条件を設定する必要があります。

JOINが発生した後、WHEREはフィルタリングします。

JOINでフィルタリングして、JOINプロセス中に行が追加されないようにします。

完全なテーブル/ビューを結合してから、結果セットの述語を導入するためにWHEREを使用するように結合することを好みます。

構文的にすっきりした感じです。

通常、結合でフィルタリングするとパフォーマンスが向上します。特に、両方のテーブルのインデックス付き列で結合できる場合。ほとんどのクエリでもこれを行うことで、論理読み取りを削減できるはずです。つまり、大容量環境では、実行時間よりもはるかに優れたパフォーマンスインジケータです。

誰かがSQLベンチマークを示し、開発サーバーで真夜中にsprocの両方のバージョンを50,000回実行し、平均時間を比較したとき、私は常に穏やかに面白がっています。

JOINが「対象」ではないため、条件を結合に入れることは「意味的に間違っている」ように見えます。しかし、それは非常に定性的です。

追加の問題：内部結合から正しい結合に切り替える場合、条件がJOIN内にあると、予期しない結果が生じる可能性があります。

テーブルが大きいほど、結合は速いと私は考えています。それは実際にはそれほど大きな違いではありませんが、特に小さいテーブルを扱っている場合はそうです。結合について初めて知ったとき、結合の条件はwhere句の条件と同じであり、条件を実行するテーブルについてwhere句が特定されていれば、条件を交換して使用できると言われました。

結合に条件を追加することをお勧めします。読みやすさよりもパフォーマンスの方が重要です。大規模なデータセットの場合は重要です。