En vedvarende utfordring i å bruke SQL er å avgjøre riktig bruk av de eksisterer og IN operatører . De to operatørene kan produsere de samme resultatene, men ikke alltid gjøre det. Også , er det stor debatt om hvordan hver operatør er optimalisert for fart. Brukerne må forstå de ulike egenskapene til hver operatør og prøve begge for å bestemme den aktuelle funksjonen . I Operator

I operatøren returnerer en rad hvis en WHERE betinget table.field verdi samsvarer med en liste over IN verdier. I brukes vanligvis som en del av en hovedbygning spørring eller i forbindelse med en underspørring

Eksempel 1: . HVOR Table.Field i (' a', 'b ', ' c' )

eksempel 2 : HVOR Table.Field i ( delspørring avkastning sett av verdier )
eksisterer Operator

eksisterer operatøren har alle de viktigste spørring rader hvis delspørringen inneholder noen rader .

eksisterer kun brukes i forbindelse med en subquery . Rader som returneres bestemmes ved filtrering på hoved spørringen nivå . Eksempel : HVOR FINNES ( delspørring avkastning sett av verdier )
forskjell

IN kan ikke vurdere NULL , så de radene er alltid falsk , og ikke returnert.

eksisterer kan vurdere NULL , så de radene kan returneres .
likheter

eksisterer og i begge støtte korrelerte og ikke- korrelerte subqueries , og begge kan produsere hoved lignende resultater. Når korrelert , finnes og i spillet en viktig spørring felt til en underspørring felt ( ex : main.id = subquery.id ) . Delspørringen evaluerer rad for rad , for hver kamp funnet. I dette tilfellet vil inn og lever tilbake de samme rader basert på lignende id kamper. Når ikke- korrelerte , eksisterer og I prosessen deres subqueries først , deretter matche resultatene til de viktigste spørringen.
Utførelse av eksisterer og IN

resultatutvikling bestemmes av database optimizer og gjennomføringsplan sysselsetter om koden henrettet . For eksisterer og IN, kan Optimizer velge ulike veier. I Oracle , dette er IKKE eksisterer unngå en anti - bli med, og vanligvis beviser raskere enn NOT IN. Til slutt blir en del prøving og feiling er nødvendig for å benchmark den raskeste veien avhengig av databasen og det er versjonen som brukes. Pass på å bruke den operatøren som sikrer de riktige resultatene først, så hvis alt er det samme , prøv å erstatte eksisterer og IN til virkelig se noe som er raskere .