Nel caso di un INNER JOIN o di una tabella a sinistra in un LEFT JOIN, in molti casi, l'ottimizzatore scoprirà che è meglio eseguire prima qualsiasi filtraggio (selettività massima) prima di eseguire effettivamente qualsiasi tipo di join fisico, quindi non c'è sono ovviamente l'ordine fisico delle operazioni che sono migliori.
In una certa misura a volte puoi controllarlo (o interferire con questo) con il tuo SQL, ad esempio, con aggregati nelle sottoquery.
L'ordine logico di elaborazione dei vincoli nella query può essere trasformato solo in base a trasformazioni invarianti note.
Quindi:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
è ancora logicamente equivalente a:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
e generalmente avranno lo stesso piano di esecuzione.
D'altra parte:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
NON è equivalente a:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
e quindi l'ottimizzatore non li trasformerà nello stesso piano di esecuzione.
L'ottimizzatore è molto intelligente ed è in grado di spostare le cose in modo abbastanza efficace, comprese le visualizzazioni compresse e le funzioni con valori di tabella in linea, nonché persino spingere le cose verso il basso attraverso determinati tipi di aggregati con successo.
In genere, quando si scrive SQL, deve essere comprensibile, gestibile e corretto. Per quanto riguarda l'efficienza nell'esecuzione, se l'ottimizzatore ha difficoltà a trasformare l'SQL dichiarativo in un piano di esecuzione con prestazioni accettabili, il codice può talvolta essere semplificato o aggiungere indici o suggerimenti appropriati o scomporsi in passaggi che dovrebbero eseguire più rapidamente - il tutto in ordini successivi di invasività.
