Den nemme guide til, hvordan du bruger underforespørgsler i SQL Server

Begge forespørgsler udsender de samme 3806 rækker.

Lad os derefter se på deres udførelsesplaner:

Figur 4:Udførelsesplan for vores andet eksempel ved hjælp af en underforespørgsel

Figur 5:Udførelsesplan for vores andet eksempel ved hjælp af en join

Kan du se de 2 udførelsesplaner og finde nogen forskel på dem? Ved et blik ser de ens ud.

Men en mere omhyggelig undersøgelse med Sammenlign Showplan afslører, hvad der virkelig er indeni.

Figur 6:Detaljer om Sammenlign Showplan for det andet eksempel

Lad os starte med at analysere et par ligheder:

• Det lyserøde højdepunkt i udførelsesplanen afslører lignende handlinger for begge forespørgsler. Da den indre forespørgsel bruger en joinforbindelse i stedet for indlejrede underforespørgsler, er dette ganske forståeligt.
• De estimerede omkostninger til operatør og undertræ er de samme.

Lad os derefter tage et kig på forskellene:

• For det første tog kompileringen længere tid, når vi brugte joins. Du kan kontrollere det i Compile CPU og Compile Time. Men forespørgslen med en underforespørgsel tog en højere kompileringshukommelse i KB.
• Så er QueryPlanHash for begge forespørgsler forskellig, hvilket betyder, at de har en anden eksekveringsplan.
• Sidst er den forløbne tid og CPU-tid til at eksekvere planen hurtigere ved at bruge joinforbindelsen end at bruge en underforespørgsel.

Underforespørgsel vs. Deltag i Performance Takeaway

Du vil sandsynligvis stå over for for mange andre forespørgselsrelaterede problemer, som kan løses ved at bruge en joinforbindelse eller en underforespørgsel.

Men bundlinjen er, at en underforespørgsel ikke i sig selv er dårlig sammenlignet med joinforbindelser. Og der er ingen tommelfingerregel om, at i en bestemt situation er en joinforbindelse bedre end en underforespørgsel eller omvendt.

Så for at sikre dig, at du har det bedste valg, skal du tjekke udførelsesplanerne. Formålet med det er at få indsigt i, hvordan SQL Server vil behandle en bestemt forespørgsel.

Men hvis du vælger at bruge en underforespørgsel, skal du være opmærksom på, at der kan opstå problemer, som vil teste dine færdigheder.

Almindelige forbehold ved brug af SQL-underforespørgsler

Der er 2 almindelige problemer, der kan få dine forespørgsler til at opføre sig vildt, når du bruger SQL-underforespørgsler.

Smerten ved opløsning af kolonnenavne

Dette problem introducerer logiske fejl i dine forespørgsler, og de kan være meget vanskelige at finde. Et eksempel kan yderligere afklare dette problem.

Lad os starte med at oprette en tabel til demoformål og udfylde den med data.

BRUG [AdventureWorks]GO-- Opret tabellen til vores demonstration baseret på LeverandørerCREATE TABLE Purchasing.MyVendors(BusinessEntity_id int,AccountNumber nvarchar(15),Name nvarchar(50))GO-- Udfyld nogle data til vores ny tabelINDSÆT I Purchasing.MyVendorsSELECT BusinessEntityID, AccountNumber, Name FROM Purchasing.VendorWHERE BusinessEntityID IN (SELECT BusinessEntityID FROM Purchasing.ProductVendor)AND BusinessEntityID like '14%'GO 

Nu hvor tabellen er sat, lad os affyre nogle underforespørgsler ved hjælp af den. Men før du udfører forespørgslen nedenfor, skal du huske, at de leverandør-id'er, vi brugte fra den forrige kode, starter med '14'.

SELECT b.Name, b.ListPrice, a.BusinessEntityIDFROM Purchasing.ProductVendor aINNER JOIN Production.Product b on a.ProductID =b.ProductIDWHERE a.BusinessEntityID IN (SELECT BusinessEntityID FROM Purchasing.MyVendors) 

Ovenstående kode kører uden fejl, som du kan se nedenfor. Under alle omstændigheder skal du være opmærksom på listen over BusinessEntityID'er .

Figur 7:Forretningsenheds-id'er for resultatsættet er inkonsistente med registreringerne i MyVendors-tabellen

Fik vi ikke indsat data med BusinessEntityID begynder med '14'? Hvad er der så i vejen? Faktisk kan vi se BusinessEntityID'er der starter med '15' og '16'. Hvor kom disse fra?

Faktisk viste forespørgslen alle data fra ProductVendor tabel.

I så fald tror du måske, at et alias vil løse dette problem, så det refererer til MyVendors tabel ligesom nedenstående:

Figur 8:Tilføjelse af et alias til BusinessEntityID'et resulterer i en fejl

Bortset fra at nu dukkede det virkelige problem op på grund af en runtime-fejl.

Tjek MyVendors tabel igen, og du vil se det i stedet for BusinessEntityID , skal kolonnenavnet være BusinessEntity_id (med en understregning).

Brug af det korrekte kolonnenavn vil derfor endelig løse dette problem, som du kan se nedenfor:

Figur 9:Ændring af underforespørgslen med det korrekte kolonnenavn løste problemet

Som du kan se ovenfor, kan vi nu observere BusinessEntityID'er starter med '14' ligesom vi tidligere har forventet.

Men du undrer dig måske: hvorfor i alverden tillod SQL Server at køre forespørgslen med succes i første omgang?

Her er kickeren:Opløsningen af ​​kolonnenavne uden alias fungerer i forbindelse med underforespørgslen fra i sig selv at gå ud til den ydre forespørgsel. Det er derfor henvisningen til BusinessEntityID inde i underforespørgslen udløste ikke en fejl, fordi den findes uden for underforespørgslen – i ProductVendor tabel.

Med andre ord leder SQL Server efter den ikke-aliasede kolonne BusinessEntityID i MyVendors bord. Da den ikke er der, kiggede den udenfor og fandt den i ProductVendor bord. Skørt, ikke?

Du kan sige, at det er en fejl i SQL Server, men faktisk er det designet i SQL-standarden, og Microsoft fulgte det.

Okay, det er klart, vi kan ikke gøre noget ved standarden, men hvordan kan vi undgå at løbe ind i en fejl?

• Først skal du præfikse kolonnenavnene med tabelnavnet eller bruge et alias. Med andre ord, undgå tabelnavne uden præfiks eller ikke-alias.
• For det andet skal du have en ensartet navngivning af kolonner. Undgå at have begge BusinessEntityID og BusinessEntity_id , for eksempel.

Lyder godt? Ja, dette bringer noget fornuft ind i situationen.

Men dette er ikke enden på det.

Crazy NULLs

Som jeg nævnte, er der mere at dække. T-SQL bruger 3-værdi logik på grund af dens understøttelse af NULL . Og NULL kan næsten gøre os vanvittige, når vi bruger SQL-underforespørgsler med NOT IN .

Lad mig starte med at introducere dette eksempel:

SELECT b.Name, b.ListPrice, a.BusinessEntityIDFROM Purchasing.ProductVendor aINNER JOIN Production.Product b on a.ProductID =b.ProductIDWHERE a.BusinessEntityID NOT IN (SELECT c.BusinessEntity_id FROM Purchasing c.MyVendorsing )

Outputtet af forespørgslen fører os til en liste over produkter, der ikke er i MyVendors tabel., som vist nedenfor:

Figur 10:Outputtet af prøveforespørgslen ved brug af NOT IN

Antag nu, at nogen utilsigtet har indsat en post i MyVendors tabel med en NULL BusinessEntity_id . Hvad skal vi gøre ved det?

Figur 11:Resultatsættet bliver tomt, når et NULL BusinessEntity_id indsættes i MyVendors

Hvor blev alle data af?

Ser du, IKKE operatør afviste IN prædikat. Så IKKE SAND bliver nu FALSK . Men IKKE NULL er Ukendt. Det fik filteret til at kassere de rækker, der er UKENDTE, og det er synderen.

For at sikre, at dette ikke sker for dig:

• Før enten tabelkolonnen til at afvise NULL hvis data ikke skulle være sådan.
• Eller tilføj kolonnenavnet ER IKKE NULL til dit Hvor klausul. I vores tilfælde er underforespørgslen som følger:

SELECT b.Name, b.ListPrice, a.BusinessEntityIDFROM Purchasing.ProductVendor aINNER JOIN Production.Product b on a.ProductID =b.ProductIDWHERE a.BusinessEntityID NOT IN (SELECT c.BusinessEntity_id FROM Purchasing c.MyVendorsing WHERE c.BusinessEntity_id IS NOT NULL)

Takeaways

Vi har talt temmelig meget om underforespørgsler, og tiden er inde til at give de vigtigste takeaways af dette indlæg i form af en opsummeret liste:

En underforespørgsel:

• er en forespørgsel i en forespørgsel.
• er omgivet af parentes.
• kan erstatte et udtryk hvor som helst.
• kan bruges i SELECT , INDSÆT , OPDATERING , SLET, eller andre T-SQL-sætninger.
• kan være selvstændig eller korreleret.
• udskriver enkelt-, multiple- eller tabelværdier.
• fungerer på sammenligningsoperatorer som =, <>,>, <,>=, <=og logiske operatorer som IN /IKKE I og FINDER /FINDER IKKE .
• er ikke dårligt eller ondt. Det kan fungere bedre eller dårligere end JOIN s afhængig af en situation. Så tag mit råd og tjek altid udførelsesplanerne.
• kan have grim adfærd på NULL s, når det bruges sammen med NOT IN , og når en kolonne ikke er eksplicit identificeret med en tabel eller tabelalias.

Get familiarized with several additional references for your reading pleasure:

• Discussion of Subqueries from Microsoft.
• IN (Transact-SQL)
• EXISTS (Transact-SQL)
• ALL (Transact-SQL)
• SOME | ANY (Transact-SQL)
• Comparison Operators