Förberedelse inför kodningsintervjuer · Lektion

EXISTS kontra IN – prestanda

När EXISTS avbryter tidigt och presterar bättre än IN – en vanlig fråga vid seniorintervjuer

Lektion 4 av 413 steg

EXISTS kontra IN – prestanda är en gratis lektion i Förberedelse inför kodningsintervjuer på CoddyKit. Detta är lektion 4 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Förberedelse inför kodningsintervjuer, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Förberedelse inför kodningsintervjuer innehåller totalt 4 lektioner.

Vad EXISTS faktiskt testar

EXISTS tar en underfråga och returnerar sant i samma ögonblick som underfrågan producerar minst en rad. Det bryr sig inte om vilka värden som returneras — bara om någon rad finns.

Det är ett booleskt test som används i WHERE.
Det är nästan alltid korrelerat: den inre frågan refererar till den yttre raden.

Den här frågan dyker upp i nästan varje SQL-intervju för roller på mellan- och seniornivå.

En enkel EXISTS-fråga

Hitta kunder som har lagt minst en beställning. Den inre frågan är korrelerad genom o.customer_id = c.id; EXISTS blir sant så snart en matchande beställning hittas.

Observera SELECT 1 — det valda värdet saknar betydelse, så de flesta utvecklare skriver 1 eller *. Intervjuare accepterar båda; optimeraren ignorerar select-listan inuti EXISTS.

SELECT c.name
FROM customers c
WHERE EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

Kortslutningsbeteende

Nyckelordet intervjuare vill höra är kortslutning. EXISTS slutar läsa den inre frågan i samma ögonblick som den hittar en matchande rad. Den behöver aldrig bygga upp eller ta bort dubbletter i hela listan med träffar.

IN materialiserar däremot begreppsmässigt mängden värden från underfrågan och kontrollerar sedan medlemskapet. För stora inre mängder eller mängder med många dubbletter spelar den skillnaden roll.

Samma fråga med IN

Här är IN-motsvarigheten till frågan om kunder med beställningar. Logiskt identiskt resultat, men annan mekanik: underfrågan är okorrelerad och producerar en lista med kund-ID:n som den yttre frågan kontrollerar mot.

Med moderna optimerare ger dessa ofta samma plan — men i stora orders med många dubbletter kan EXISTS vara snabbare eftersom den stannar vid den första träffen.

SELECT c.name
FROM customers c
WHERE c.id IN (
  SELECT o.customer_id FROM orders o
);

NOT EXISTS är bättre än NOT IN

Det här är poängen med hela lektionen. NOT EXISTS är det säkra sättet att uttrycka en anti-join. Till skillnad från NOT IN påverkas den inte felaktigt av NULL-värden i den inre frågan.

Det här hittar tillförlitligt varje kund utan beställningar, även om orders.customer_id innehåller NULL-värden.

SELECT c.name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

Varför NOT EXISTS är NULL-säkert

NOT EXISTS frågar bara hittade den korrelerade underfrågan någon matchande rad? — ett tydligt ja eller nej. En NULL i customer_id uppfyller helt enkelt aldrig o.customer_id = c.id, så den varken matchar eller förgiftar logiken.

Jämför med NOT IN, där ett NULL i listan tvingar fram UNKNOWN och tar bort alla rader. Det är därför seniorintervjuare föredrar NOT EXISTS för anti-joins.

När IN faktiskt är bättre

Ha ett nyanserat svar — IN är inte alltid sämre. När underfrågan returnerar en liten, statisk och dubblettfri lista är IN tydligt och snabbt:

En handfull literalvärden eller en mycket liten uppslagstabell.
En okorrelerad fråga som optimeraren kan köra en gång och cacha.

Frågan nedan är helt idiomatisk; att använda EXISTS här skulle vara överkonstruktion.

SELECT name
FROM products
WHERE category_id IN (
  SELECT id FROM categories WHERE active = true
);

Det ärliga moderna svaret

Mogna optimerare (Postgres, senare versioner av SQL Server och MySQL) skriver ofta om IN och EXISTS till samma semi-join-plan. För vanligt positivt medlemskap är prestandan därför ofta identisk.

Skillnaderna som fortfarande spelar roll:

NOT IN kontra NOT EXISTS — korrekthet med NULL-värden, inte bara hastighet.
Mycket stora eller oindexerade inre tabeller — EXISTS kortsluter.

EXISTS kontra JOIN för förekomst

En annan vinkel som intervjuare tar upp: varför inte bara använda JOIN? En join som bara kontrollerar förekomst kan multiplicera rader om den högra sidan innehåller dubbletter, vilket tvingar fram en DISTINCT. EXISTS duplicerar aldrig den yttre raden.

För en ren förekomstskontroll är EXISTS därför renare än JOIN ... DISTINCT. Använd en join när Ni faktiskt behöver kolumner från den andra tabellen.

SELECT DISTINCT c.name
FROM customers c
JOIN orders o ON o.customer_id = c.id;

Indexering avgör prestandan

Det går inte att ge ett komplett prestandasvar utan index. En korrelerad EXISTS gör den inre uppslagningen för varje yttre rad, så ett index på den korrelerade kolumnen — här orders(customer_id) — är det som gör den snabb.

Att nämna "Jag skulle indexera join-kolumnen som underfrågan korrelerar på" förvandlar ett lärobokssvar till ett praktiskt svar som intervjuare respekterar.

CREATE INDEX idx_orders_customer_id
  ON orders (customer_id);

Intervjuformulering

Säg: "EXISTS är ett korrelerat booleskt test som kortsluter vid den första matchande raden, medan IN testar medlemskap i en värdelista. För positiva kontroller ger moderna optimerare ofta samma semi-join-plan. Den verkliga skillnaden är NOT EXISTS kontra NOT IN: NOT EXISTS är NULL-säkert, så jag föredrar det för anti-joins — och jag ser till att den korrelerade kolumnen är indexerad."

Snabbtest

Kärnan i diskussionen om EXISTS kontra IN.

Besvara frågan i den interaktiva lektionen

Sammanfattning

EXISTS kontra IN, avgjort:

EXISTS är ett korrelerat booleskt test som kortsluter vid den första matchande raden; select-listan inuti saknar betydelse.
IN kontrollerar medlemskap i en värdemängd och passar utmärkt för små, dubblettfria och okorrelerade listor.
För positiva kontroller väljer moderna optimerare ofta samma semi-join-plan.
Föredra NOT EXISTS framför NOT IN för anti-joins — det är NULL-säkert. Indexera den korrelerade kolumnen.

Det avslutar kursen Subqueries Deep Dive.

Gratis att börja

Lär dig Förberedelse inför kodningsintervjuer med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 90
Lektioner: 360

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”EXISTS kontra IN – prestanda” gratis?

Ja – hela texten till ”EXISTS kontra IN – prestanda” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Förberedelse inför kodningsintervjuer, kan Ni uppgradera till CoddyKit PRO. Kursen i Förberedelse inför kodningsintervjuer innehåller totalt 4 lektioner.

Vad lär jag mig i ”EXISTS kontra IN – prestanda”?

När EXISTS avbryter tidigt och presterar bättre än IN – en vanlig fråga vid seniorintervjuer Ni övar på Förberedelse inför kodningsintervjuer med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Förberedelse inför kodningsintervjuer?

Du behöver inga förkunskaper. Utbildningen i Förberedelse inför kodningsintervjuer på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 4 av 4.

Hur lång tid tar lektionen ”EXISTS kontra IN – prestanda”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Förberedelse inför kodningsintervjuer-lektionen?

Ja. Varje Förberedelse inför kodningsintervjuer-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

Skalära underfrågor i SELECT och WHERE
Underfrågor i FROM-satsen (härledda tabeller)
IN-, ANY- och ALL-underfrågor
EXISTS kontra IN – prestanda

← Tillbaka till Förberedelse inför kodningsintervjuer