Condizioni all'interno di JOIN o WHERE

C'è qualche differenza (performance, best practice, ecc ...) tra l'inserimento di una condizione nella clausola JOIN e la clausola WHERE?

Per esempio...

-- 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'

Quale preferisci (e forse perché)?

L'algebra relazionale consente l'interscambiabilità dei predicati nella WHEREclausola e la INNER JOIN, quindi anche le INNER JOINquery con WHEREclausole possono far risistemare i predicati dall'ottimizzatore in modo che possano essere già esclusi durante il JOINprocesso.

Ti consiglio di scrivere le domande nel modo più leggibile possibile.

A volte ciò include rendere INNER JOINrelativamente "incompleto" e inserire alcuni dei criteri WHEREsemplicemente per rendere più facilmente gestibili gli elenchi dei criteri di filtro.

Ad esempio, anziché:

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

Scrivi:

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

Ma dipende, ovviamente.

Per i join interni non ho notato alcuna differenza (ma come per tutte le ottimizzazioni delle prestazioni, è necessario controllare il database in base alle proprie condizioni).

Tuttavia, se si inserisce la condizione, la differenza è enorme se si utilizzano i join destro o sinistro. Ad esempio, considera queste due query:

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'

Il primo ti darà solo quei record che hanno un ordine datato dopo il 15 maggio 2009, convertendo così il join sinistro in un join interno.

Il secondo fornirà quei record più eventuali clienti senza ordini. Il set di risultati è molto diverso a seconda di dove si inserisce la condizione. (Seleziona * è solo a scopo di esempio, ovviamente non dovresti usarlo nel codice di produzione.)

L'eccezione a ciò è quando si desidera vedere solo i record in una tabella ma non nell'altra. Quindi si utilizza la clausola where per la condizione, non il join.

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

La maggior parte dei prodotti RDBMS ottimizzerà entrambe le query in modo identico. In "SQL Performance Tuning" di Peter Gulutzan e Trudy Pelzer, hanno testato più marchi di RDBMS e non hanno riscontrato differenze di prestazioni.

Preferisco mantenere le condizioni di join separate dalle condizioni di restrizione della query.

Se si utilizza a OUTER JOINvolte è necessario inserire le condizioni nella clausola di join.

DOVE filtra dopo che si è verificato il JOIN.

Filtro su JOIN per impedire l'aggiunta di righe durante il processo JOIN.

Preferisco JOIN per unire tabelle / viste complete e quindi utilizzare WHERE per introdurre il predicato dell'insieme risultante.

Sembra sintatticamente più pulito.

In genere vedo un aumento delle prestazioni durante il filtraggio sul join. Soprattutto se puoi unirti su colonne indicizzate per entrambe le tabelle. Dovresti essere in grado di ridurre le letture logiche eseguendo anche la maggior parte delle query, che è, in un ambiente ad alto volume, un indicatore di prestazioni molto migliore rispetto ai tempi di esecuzione.

Sono sempre leggermente divertito quando qualcuno mostra il suo benchmarking SQL e ha eseguito entrambe le versioni di uno sproc 50.000 volte a mezzanotte sul server di sviluppo e confrontando i tempi medi.

Mettere la condizione nel join mi sembra "semanticamente sbagliato", dato che non è quello per cui i JOIN sono "per". Ma è molto qualitativo.

Ulteriore problema: se si decide di passare da un join interno a, diciamo, a un join destro, la condizione all'interno del JOIN potrebbe portare a risultati imprevisti.

Le iscrizioni sono più veloci secondo me quando hai un tavolo più grande. In realtà non fa molta differenza, soprattutto se si ha a che fare con una tabella piuttosto piccola. Quando ho appreso per la prima volta dei join, mi è stato detto che le condizioni nei join sono proprio come le condizioni della clausola where e che potrei usarle in modo intercambiabile se la clausola where fosse specifica su quale tabella applicare la condizione.

È meglio aggiungere la condizione nel Join. Le prestazioni sono più importanti della leggibilità. Per set di dati di grandi dimensioni, è importante.