WHERE-satsen körs bättre före IN och JOIN eller efter

I fallet med en INNER JOIN eller en tabell till vänster i en LEFT JOIN, i många fall, kommer optimeraren att upptäcka att det är bättre att utföra någon filtrering först (högsta selektiviteten) innan man faktiskt utför vilken typ av fysisk koppling som helst - så där är uppenbarligen fysisk ordning för operationer som är bättre.

Till viss del kan du ibland kontrollera detta (eller störa detta) med din SQL, till exempel med aggregat i underfrågor.

Den logiska ordningen för att bearbeta begränsningarna i frågan kan endast transformeras enligt kända invarianta transformationer.

Så:

SELECT *
FROM a
INNER JOIN b
    ON a.id = b.id
WHERE a.something = something
    AND b.something = something

är fortfarande logiskt sett likvärdig med:

SELECT *
FROM a
INNER JOIN b
    ON a.id = b.id
    AND a.something = something
    AND b.something = something

och de kommer i allmänhet att ha samma utförandeplan.

Å andra sidan:

SELECT *
FROM a
LEFT JOIN b
    ON a.id = b.id
WHERE a.something = something
    AND b.something = something

motsvarar INTE:

SELECT *
FROM a
LEFT JOIN b
    ON a.id = b.id
    AND a.something = something
    AND b.something = something

och så optimeraren kommer inte att förvandla dem till samma exekveringsplan.

Optimeraren är mycket smart och kan flytta runt saker ganska framgångsrikt, inklusive kollapsande vyer och inline-tabellvärderade funktioner samt till och med trycka ner saker genom vissa typer av aggregat ganska framgångsrikt.

Vanligtvis när du skriver SQL måste det vara begripligt, underhållbart och korrekt. När det gäller effektivitet i exekvering, om optimeraren har svårt att omvandla den deklarativa SQL-en till en exekveringsplan med acceptabel prestanda, kan koden ibland förenklas eller lämpliga index eller tips läggas till eller delas upp i steg som bör> prestera snabbare - allt i följd av invasivitet.