Ho due esempi seguenti.SQL JOIN dove posizionare la condizione WHERE?
1. Esempio (DOVE)
SELECT 1
FROM table1 t1
JOIN table2 t2 ON t1.id = t2.id
WHERE t2.field = true
2. Esempio (aderire e)
SELECT 1
FROM table1 t1
JOIN table2 t2 ON t1.id = t2.id AND t2.field = true
Qual è il modo più veloce in termini di prestazioni? Cosa preferisci?
Se un filtro entra in una condizione JOIN funzionalmente (cioè è una condizione di unione reale, non solo un filtro), deve apparire nella clausola ON di tale join.
Da segnalare:
Se lo si inserisce nella clausola WHERE invece, le performance sono lo stesso se il join è INNER, altrimenti si differenzia. Come accennato nei commenti, non ha molta importanza dal momento che il risultato è diverso.
Posizionamento del filtro nella clausola WHERE quando è davvero una condizione OUTER JOIN annulla implicitamente la OUTER natura della condizione ("join anche quando non ci sono record") come questi filtri implicano record ci deve essere esistente nella prima posto. Esempio:
... table1 t LEFT JOIN table2 u ON ... AND t2.column = 5 è corretto
... table1 t LEFT JOIN table2 u ON ...
WHERE t2.column = 5
non è corretto, come t2.column = 5 indica al motore che registra da T2 sono attesi, che va contro l'outer join. Eccezione a questo sarebbe un filtro IS NULL, come WHERE t2.column IS (NOT) NULL (che è in realtà un modo conveniente per costruire esterno condizionale join)
LEFT e RIGHT join sono implicitamente OUTER join.Spero che sia stato di aiuto.
JOIN Le condizioni dovrebbero normalmente essere indipendenti dalle condizioni del filtro. Definisci le regole del tuo join (il come) con ON. Filtra cosa vuoi con WHERE. Per quanto riguarda le prestazioni, non esiste una regola generale per tutti i motori e i progetti, quindi il tuo chilometraggio può variare notevolmente.
Penso che il modo più veloce sia quello di inserire il filtro nella clausola where, poiché esso proclaggerà quel filtro nel primo dove, e quindi nella clausola join, quindi non ci sarà bisogno di permutazione dei filtri.
Non c'è alcuna differenza per un DBMS con alcuna ottimizzazione. Ad esempio, consultare la documentazione di MySQL sull'ottimizzazione SELECT/JOIN: un JOINT INNER JOIN viene trattato come se fosse un WHERE applicato a quel JOIN. – philipxy
Questa risposta contiene una scrittura sbagliata e confusa. 1. Per INNER JOIN qualsiasi condizione può essere in un WHERE anziché in ON fintanto che non vi è alcun OUTER JOIN intermedio. 2. Quando si sposta una condizione LEFT JOIN da ON a WHERE la performance è irrilevante poiché (come dici tu) in generale il risultato è diverso. 3. Questa differenza in generale non "trasforma l'ESTERNO ORA in un GIUNTO INTERNO". – philipxy
@philipxy hai ragione, ho provato a ripulire un po ' – Sebas
Che cosa significa "un filtro entra in una condizione JOIN funzionalmente" o "[un filtro] è una condizione di unione effettiva, non solo un filtro"? Ad ogni modo, la nozione di "solo un filtro" non è utile poiché il significato di "UNISCI SULLA c AND d" è lo stesso di "UNISCI SULLA c WHERE d'. (In effetti lo standard SQL * definisce * JOIN ON in termini di JOIN WHERE.) Allo stesso modo "annulla implicitamente la natura ESTERNA della condizione" * semplicemente non comunica nulla *. A quale sembra essere d'accordo dato che l'hai annotato con lo spavento quotato (quindi non chiaro) '("unisciti anche quando non ci sono record") ". Non stai spiegando. – philipxy