clausola WHERE vs ON quando si utilizza JOIN

Question

Supponendo che ho il seguente codice T-SQL:

SELECT * FROM Foo f 
INNER JOIN Bar b ON b.BarId = f.BarId; 
WHERE b.IsApproved = 1; 

Il seguente si ritorna anche lo stesso insieme di righe:

SELECT * FROM Foo f 
INNER JOIN Bar b ON (b.IsApproved = 1) AND (b.BarId = f.BarId); 

questo potrebbe non essere il miglior esempio di caso qui, ma c'è qualche differenza di prestazioni tra questi due?

Answer 1

No, il Query Optimizer è abbastanza intelligente da scegliere lo stesso piano di esecuzione per entrambi gli esempi.

È possibile utilizzare SHOWPLAN per verificare il piano di esecuzione.

---

Tuttavia, si dovrebbe mettere tutti si uniscono collegamento sulla clausola ON e tutte le restrizioni alla clausola di WHERE.

Answer 2

SELECT * FROM Foo f 
INNER JOIN Bar b ON b.BarId = f.BarId 
WHERE b.IsApproved = 1; 

Questa è la soluzione migliore. È facile da leggere e facile da modificare. Nel mondo degli affari questo è ciò che vorresti fare. Per quanto riguarda le prestazioni sono uguali però.

Answer 3

Basta fare attenzione alla differenza con i giunti esterni. Una query in cui viene aggiunto un filtro di b.IsApproved (sul tavolo a destra, Bar) alla ON condizione del JOIN:

SELECT * 
FROM Foo f 
LEFT OUTER JOIN Bar b ON (b.IsApproved = 1) AND (b.BarId = f.BarId); 

è NON lo stesso come mettere il filtro nella clausola WHERE:

SELECT * 
FROM Foo f 
LEFT OUTER JOIN Bar b ON (b.BarId = f.BarId) 
WHERE (b.IsApproved = 1); 

Dal momento che per 'fallito' outer join a Bar (cioè dove non c'è b.BarId per un f.BarId), questo lascerà b.IsApproved come NULL per tutti come fa Iled unisce le righe e queste verranno quindi filtrate.

Un altro modo di vedere questo è che per la prima interrogazione, LEFT OUTER JOIN Bar b ON (b.IsApproved = 1) AND (b.BarId = f.BarId) sarà sempre tornare le righe della tabella SINISTRA, dal momento che garantisce LEFT OUTER JOIN le righe della tabella SINISTRA saranno restituiti anche se il join non riesce. Tuttavia, l'effetto dell'aggiunta diallo stato LEFT OUTER JOIN a condizione è di escludere qualsiasi colonna della tabella destra quando (b.IsApproved = 1) è falso, vale a dire secondo le stesse regole normalmente applicate a una condizione LEFT JOIN su (b.BarId = f.BarId).

Aggiornamento: Per completare la domanda posta da Conrad, il LOJ equivalente per un filtro opzionale sarebbe:

SELECT * 
FROM Foo f 
LEFT OUTER JOIN Bar b ON (b.BarId = f.BarId) 
WHERE (b.IsApproved IS NULL OR b.IsApproved = 1); 

cioè la WHERE clausola deve considerare sia la condizione se il join non riesce (NULL) e il filtro deve essere ignorato e dove l'unione riesce e il filtro deve essere applicato.(b.IsApproved o b.BarId potrebbe essere testato per NULL)

ho messo un SqlFiddle together here che dimostra le differenze tra i vari piazzamenti del b.IsApproved del filtro rispetto al JOIN.

Answer 4

Mi sembra che alcuni casi in cui l'ottimizzatore non fosse abbastanza intelligente anche nelle versioni recenti di MSSQL - e la differenza di prestazioni era mostruosa.

Ma questa è un'eccezione, la maggior parte del tempo con SQL Server Optimizer risolverà il problema e otterrà il piano giusto.

Quindi mantenere la politica di utilizzo dei filtri nella clausola WHERE e ottimizzare quando necessario.

Answer 5

Ho appena eseguito un test di una query su quattro tabelle: una tabella primaria con tre JOIN INNER e un totale di quattro parametri e ha confrontato i piani di esecuzione di entrambi gli approcci (utilizzando i criteri di filtro nell'On della JOIN, e poi anche nella clausola WHERE).

I piani di esecuzione sono esattamente gli stessi. Ho eseguito questo su SQL Server 2008 R2.