Het hangt er echt van af, ik had situaties waarin ik sommige zoekopdrachten verbeterde door subquery's te gebruiken.
De factoren die ik ken zijn:
- of de subquery ter vergelijking velden uit de buitenste query gebruikt of niet (gecorreleerd of niet)
- als de relatie tussen de buitenste query en de subquery wordt gedekt door indexen
- als er geen bruikbare indexen op de joins zijn en de subquery niet gecorreleerd is en een klein resultaat oplevert, is het misschien sneller om deze te gebruiken
- ik ben ook situaties tegengekomen waarin ik een zoekopdracht die order by gebruikt, transformeert in een zoekopdracht die deze niet gebruikt en er vervolgens een eenvoudige subquery van maakt en sorteert die de prestaties in mysql verbetert
Hoe dan ook, het is altijd goed om verschillende varianten te testen (met SQL_NO_CACHE aub), en het omzetten van gecorreleerde queries in joins is een goede gewoonte.
Ik zou zelfs zo ver willen gaan om het een zeer nuttige praktijk te noemen.
Het kan zijn dat als gecorreleerde queries het eerste in je opkomen dat je niet primair denkt in termen van setoperaties, maar vooral in termen van procedurele operaties en dat het bij het omgaan met relationele databases erg handig is om de set volledig over te nemen perspectief op het datamodel en transformaties daarop.
EDIT:Procedureel versus relationeel
Denken in termen van reeksbewerkingen versus procedureel komt neer op equivalentie in sommige verzamelingsalgebra-uitdrukkingen, bijvoorbeeld selectie op een unie is gelijk aan unie van selecties. Er is geen verschil tussen de twee.
Maar als je de twee procedures vergelijkt, zoals het toepassen van de selectiecriteria op elk element van een vakbond met een vakbond maken en vervolgens selectie toepassen, zijn de twee duidelijk verschillende procedures, die hebben zeer verschillende eigenschappen (bijvoorbeeld gebruik van CPU, I/O, geheugen).
Het idee achter relationele databases is dat u niet probeert te beschrijven hoe u het resultaat (procedure) kunt krijgen, maar alleen wat u wilt, en dat het databasebeheersysteem zal beslissen over het beste pad (procedure) om aan uw verzoek te voldoen. Dit is de reden waarom SQL 4e generatie taal (4GL) wordt genoemd .
Een van de trucs die je daarbij helpen, is jezelf eraan te herinneren dat tuples geen inherente volgorde hebben (set-elementen zijn ongeordend). uw model vertegenwoordigt goed de probleemruimte, of met andere woorden als de betekenis die aan de naam van uw tabellen en relaties is gehecht goed is gedaan, of met andere woorden als uw database goed is ontworpen).
U hoeft dus niet na te denken over hoe, maar alleen over wat.
In jouw geval was het gewoon de voorkeur boven gecorreleerde zoekopdrachten, dus het kan zijn dat ik je niets nieuws vertel, maar je benadrukte dat punt, vandaar de opmerking.
Ik denk dat als je helemaal vertrouwd zou zijn met alle regels die zoekopdrachten van het ene formulier in het andere transformeren (regels zoals distributiviteit) dat u niet de voorkeur geeft aan gecorreleerde subquery's (dat u alle vormen als gelijk zou zien).
(Opmerking:hierboven bespreekt theoretische achtergrond, belangrijk voor databaseontwerp; praktisch wijken de bovenstaande concepten af - niet alle equivalente herschrijvingen van een query worden noodzakelijkerwijs uitgevoerd omdat snelle, geclusterde primaire sleutels ervoor zorgen dat tabellen de volgorde van overerven op schijf hebben, enz... maar deze afwijkingen zijn slechts afwijkingen; het feit dat niet alle equivalente zoekopdrachten even snel worden uitgevoerd, is een onvolkomenheid van het eigenlijke DBMS en niet van de concepten erachter)