Det beror verkligen på, jag hade situationer där jag förbättrade vissa frågor genom att använda underfrågor.
De faktorer som jag känner till är:
- om underfrågan använder fält från yttre fråga för jämförelse eller inte (korrelerade eller inte)
- om relationen mellan den yttre frågan och underfrågan täcks av index
- om det inte finns några användbara index på kopplingarna och underfrågan inte är korrelerad och returnerar ett litet resultat kan det vara snabbare att använda det
- Jag har också stött på situationer där man omvandlar en fråga som använder order by till en fråga som inte använder den och än omvandlar den till en enkel underfråga och sortering som förbättrar prestandan i mysql
Hur som helst, det är alltid bra att testa olika varianter (med SQL_NO_CACHE tack), och att förvandla korrelerade frågor till joins är en bra praxis.
Jag skulle till och med gå så långt att kalla det en mycket användbar praxis.
Det kan vara möjligt att om korrelerade frågor är de första som du tänker på att du inte i första hand tänker i termer av uppsättningsoperationer, utan främst i termer av proceduroperationer och när du hanterar relationsdatabaser är det mycket användbart att fullt ut använda uppsättningen. perspektiv på datamodellen och transformationer på den.
EDIT:Procedurell vs relationell
Tänk i termer av mängdoperationer vs procedur handlar om ekvivalens i vissa mängd algebrauttryck, till exempel är urval på en union likvärdig med union av urval. Det är ingen skillnad mellan de två.
Men när du jämför de två procedurerna, som att tillämpa urvalskriterierna på varje del av ett förbund med att skapa ett fackförbund och sedan tillämpa urval, är de två distinkt olika procedurer, vilket kan har mycket olika egenskaper (till exempel utnyttjande av CPU, I/O, minne).
Tanken bakom relationsdatabaser är att du inte försöker beskriva hur du får resultatet (förfarandet), utan bara vad du vill, och att databashanteringssystemet kommer att besluta om den bästa vägen (förfarandet) för att uppfylla din begäran. Det är därför SQL kallas 4:e generationens språk (4GL) .
Ett av knepen som hjälper dig att göra det är att påminna dig själv om att tupler inte har någon inneboende ordning (uppsättningselement är oordnade). Ett annat är att inse att relationalgebra är ganska omfattande och tillåter översättning av förfrågningar (krav) direkt till SQL (om semantik av din modell representerar väl problemutrymmet, eller med andra ord om betydelsen kopplad till namnet på dina tabeller och relationer görs rätt, eller med andra ord om din databas är väl utformad).
Därför behöver du inte tänka på hur, bara vad.
I ditt fall var det bara att föredra framför korrelerade frågor, så det kan vara så att jag inte berättar något nytt för dig, men du betonade den punkten, därav kommentaren.
Jag tror att om du var helt bekväm med alla regler som omvandlar frågor från en form till en annan (regler såsom distributionsförmåga) att du inte skulle föredra korrelerade underfrågor (att du skulle se alla former som lika).
(Notera:ovan diskuterar teoretisk bakgrund, viktig för databasdesign; praktiskt taget avviker ovanstående begrepp - inte alla motsvarande omskrivningar av en fråga exekveras nödvändigtvis eftersom snabba, klustrade primärnycklar gör att tabeller har ärvordning på disken, etc... men dessa avvikelser är bara avvikelser; det faktum att inte alla likvärdiga frågor körs lika snabbt är en ofullkomlighet av det faktiska DBMS och inte konceptet bakom det)