Det afhænger virkelig af, jeg havde situationer, hvor jeg forbedrede nogle forespørgsler ved at bruge underforespørgsler.
De faktorer, som jeg er klar over, er:
- hvis underforespørgslen bruger felter fra ydre forespørgsel til sammenligning eller ej (korreleret eller ej)
- hvis forholdet mellem den ydre forespørgsel og underforespørgsel er dækket af indekser
- hvis der ikke er brugbare indekser på joins, og underforespørgslen ikke er korreleret og returnerer et lille resultat, kan det være hurtigere at bruge det
- Jeg er også stødt på situationer, hvor jeg transformerer en forespørgsel, der bruger orden ved til en forespørgsel, der ikke bruger den, og end at omdanne den til en simpel underforespørgsel og sortering, der forbedrer ydeevnen i mysql
Under alle omstændigheder er det altid godt at teste forskellige varianter (med SQL_NO_CACHE tak), og at omdanne korrelerede forespørgsler til joins er en god praksis.
Jeg vil endda gå så langt for at kalde det en meget nyttig praksis.
Det kan være muligt, at hvis korrelerede forespørgsler er de første, du tænker på, at du ikke primært tænker i termer af sætoperationer, men primært i form af proceduremæssige operationer, og når du beskæftiger dig med relationelle databaser, er det meget nyttigt fuldt ud at adoptere sættet. perspektiv på datamodellen og transformationer på den.
EDIT:Procedurel vs Relationel
Tænkning i termer af mængdeoperationer vs. procedurer bunder i ækvivalens i nogle sæt algebraudtryk, for eksempel er selektion på en forening ækvivalent med forening af selektioner. Der er ingen forskel på de to.
Men når du sammenligner de to procedurer, såsom at anvende udvælgelseskriterierne på hvert element i en fagforening med oprette en fagforening og derefter anvende udvælgelse, er de to helt forskellige procedurer, hvilket kan har meget forskellige egenskaber (f.eks. udnyttelse af CPU, I/O, hukommelse).
Tanken bag relationelle databaser er, at du ikke forsøger at beskrive, hvordan du får resultatet (proceduren), men kun hvad du ønsker, og at databasestyringssystemet vil beslutte den bedste vej (procedure) til at opfylde din anmodning. Det er derfor, SQL kaldes 4. generations sprog (4GL) .
Et af de tricks, der hjælper dig med at gøre det, er at minde dig selv om, at tupler ikke har nogen iboende rækkefølge (sæt elementer er uordnede). En anden er at indse, at relationel algebra er ret omfattende og tillader oversættelse af anmodninger (krav) direkte til SQL (hvis semantik af din model repræsenterer godt problemrummet, eller med andre ord, hvis betydning knyttet til navnet på dine tabeller og relationer er gjort rigtigt, eller med andre ord, hvis din database er designet godt).
Derfor behøver du ikke tænke hvordan, kun hvad.
I dit tilfælde var det bare præference frem for korrelerede forespørgsler, så det kan være, at jeg ikke fortæller dig noget nyt, men du understregede det punkt, deraf kommentaren.
Jeg tror, at hvis du var helt fortrolig med alle de regler, der transformerer forespørgsler fra en formular til en anden (regler såsom distributivitet), at du ikke ville foretrække korrelerede underforespørgsler (at du ville se alle former som lige).
(Bemærk:Ovenstående diskuterer teoretisk baggrund, vigtig for databasedesign; praktisk talt afviger ovenstående begreber - ikke alle ækvivalente omskrivninger af en forespørgsel udføres nødvendigvis, da hurtige, klyngede primærnøgler gør, at tabeller har arveret rækkefølge på disken osv... men disse afvigelser er kun afvigelser; det faktum, at ikke alle tilsvarende forespørgsler udføres så hurtigt, er en ufuldkommenhed af det faktiske DBMS og ikke koncepterne bag det)