WHERE-klausulen udføres bedre før IN og JOIN eller efter

I tilfælde af en INNER JOIN eller en tabel til venstre i en LEFT JOIN, vil optimeringsværktøjet i mange tilfælde finde ud af, at det er bedre at udføre enhver filtrering først (højeste selektivitet), før man rent faktisk udfører en hvilken som helst type fysisk joinforbindelse - så der er åbenlyst fysisk rækkefølge af operationer, som er bedre.

Til en vis grad kan du nogle gange kontrollere dette (eller forstyrre dette) med din SQL, for eksempel med aggregater i underforespørgsler.

Den logiske rækkefølge for behandling af begrænsningerne i forespørgslen kan kun transformeres i henhold til kendte invariante transformationer.

Så:

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

er stadig logisk svarende til:

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

og de vil generelt have den samme udførelsesplan.

På den anden side:

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

svarer IKKE til:

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

og derfor vil optimeringsværktøjet ikke omdanne dem til den samme eksekveringsplan.

Optimeringsværktøjet er meget smart og er i stand til at flytte rundt på tingene med stor succes, inklusive kollapsende visninger og inline-tabelvurderede funktioner samt endda skubbe tingene ned gennem visse typer aggregater med nogenlunde succes.

Typisk, når du skriver SQL, skal det være forståeligt, vedligeholdeligt og korrekt. Hvad angår effektivitet i eksekveringen, hvis optimeringsværktøjet har svært ved at omdanne den deklarative SQL til en eksekveringsplan med acceptabel ydeevne, kan koden nogle gange forenkles eller passende indekser eller hints tilføjes eller opdeles i trin, som bør> præstere hurtigere - alt sammen i successive rækkefølger af invasivitet.