Beste svaret
Selv om både sammenføyninger og underforespørsler har sin plass i SQL-setninger, prøver jeg personlig alltid å skrive spørsmålene mine ved hjelp av sammenføyninger . I mellomtiden introduserer jeg bare et undersøk når jeg ikke kan hente dataene jeg vil ha uten en.
Årsaken er at joins har en tendens til å utføres raskere. Faktisk vil jeg gå så langt som å si at hentetiden for spørringen ved hjelp av sammenføyninger nesten alltid vil være raskere enn for en underspørsel.
Årsaken er at sammenføyninger lindrer beregningsbyrden på database ved å erstatte flere spørsmål med ett delta-spørsmål. Dette utnytter i sin tur bedre databasens evner til å søke gjennom, filtrere og sortere poster.
Selvfølgelig, når du legger til flere sammenføyninger til et spørsmål, må databaseserveren gjøre mer arbeid, som oversettes for å redusere datainnhentingstider.
Selv om sammenføyninger er nødvendige for å hente data fra en normalisert database, er det viktig at sammenføyninger skrives riktig, ettersom feil sammenføyning kan føre til alvorlig ytelsesnedbrytning og unøyaktige spørringsresultater.
I noen tilfeller kan underspøringer erstatte komplekse sammenføyninger og fagforeninger med bare en minimal negativ effekt på ytelsen.
Eksempler på underspørsmål
Noen ganger kan du ikke virkelig komme deg rundt ved hjelp av et underspørsmål. Her er et par eksempler som bruker Sakila Sample Database for MySQL og min Navicat databaseutvikling og admin-klient.
Eksempel 1: Bruke en samlet funksjon som en del av en JOIN-klausul
Mesteparten av tiden blir tabeller slått sammen på et felles felt. Det er faktisk ikke uvanlig at det vanlige feltet også har samme navn for å vise at det er de samme dataene. I det følgende spørsmålet blir kundetabellen imidlertid knyttet til den siste (MAX) create\_date, slik at søkeresultatene er for kunden som nylig registrerte seg.
Det brukes et underspørsmål fordi du ikke kan bruke samlede funksjoner. som en del av en WHERE-klausul. Denne geniale løsningen omgår den begrensningen!
Eksempel nr. 2:
I dette spørsmålet brukes et underspørsmål for å hente et mellomliggende resultatsett slik at vi kan bruke AVG () -funksjonen på ANTALL leide filmer. Dette er det jeg kaller en dobbel aggregering fordi vi bruker en aggregering (AVG) til resultatet av en annen (COUNT).
Dette spesielle spørsmålet er ganske raskt – tar bare 0,044 sekunder – fordi det indre spørsmålet returnerer en enkelt verdi. Vanligvis er de tregeste spørsmålene de som krever fullstendige tabellskanninger.
Håper det svarer på spørsmålet ditt.
Hilsen!
Adam
Svar
Vanligvis bør du skrive spørsmål for å være så tydelige som mulig og overlate optimaliseringen til RDBMS spørringsprosessor og DBA, hvis du har en som er ansvarlig for å innstille den fysiske utformingen. Dette burde resultere i god nok ytelse i de fleste tilfeller, men det er unntak. Noen ganger har en RDBMS spørringsoptimerer blinde flekker eller dårlige tilfeller.
Nå hvis enten sammenføyninger eller underspørsmål kommer til å være et problem for en optimizer, er det mye mer sannsynlig at det er i underspørsmål. Det er fordi sammenføyning er en grunnleggende funksjon i språket som alle bruker, mens mange brukere ikke bruker underspørsmål i det hele tatt. Jeg fant ut at konvertering av en app fra Sybase til SQL Server måtte jeg omskrive mange underspørsmål som sammenføyninger på grunn av feil i Microsoft håndtering av delspørsmål – om enn i et veldig spesifikt tilfelle (der delspørringen der klausulen inkluderte en bundet parameter). Det er ikke overraskende at SQL Server hadde feil i underspørringer fordi så mange av kundene bruker SQL Server sammen med Microsofts grafiske spørreredaktører som naturlig produserer sammenføyninger, men ikke underforespørsler.
Jeg anbefaler vanligvis ikke for tidlig optimalisering, men jeg vil gjøre et unntak her. Hvis søknaden din må være bærbar på tvers av flere databaseplattformer, foretrekker jeg å bli med på underspørsler i de fleste tilfeller fordi det er større sannsynlighet for at du får feil eller dårlige optimeringsvalg med underspørsmål applikasjonen trenger ikke å være bærbar, skriv spørringen på det som virker mest naturlig, og hvis det ikke er noe problem – som vil være mesteparten av tiden – greit. Hvis det er et problem, skriv om spørsmålet på en annen måte for å se om det hjelper. Og hvis du har en DBA, så kontakt ham om eventuelle ytelsesproblemer du har.