Korrelerad underfråga
I en SQL- databasfråga är en korrelerad underfråga ( även känd som en synkroniserad underfråga ) en underfråga (en fråga kapslad inuti en annan fråga) som använder värden från den yttre frågan. Eftersom underfrågan kan utvärderas en gång för varje rad som bearbetas av den yttre frågan, kan den vara långsam.
Exempel
Här är ett exempel på en typisk korrelerad underfråga. I det här exemplet är målet att hitta alla anställda vars lön är över genomsnittet för deras avdelning.
VÄLJ anställd_nummer , namn FRÅN anställda emp WHERE lön > ( VÄLJ AVG ( lön ) FRÅN anställda WHERE avdelning = anställd avdelning ) ;
I ovanstående fråga är den yttre frågan
VÄLJ anställd_nummer , namn FRÅN anställda anställd VAR lön > ...
och den inre frågan (den korrelerade underfrågan) är
VÄLJ AVG ( lön ) FRÅN anställda VAR avdelning = anm . avdelning
I den kapslade frågan ovan måste den inre frågan köras om för varje anställd. (En tillräckligt smart implementering kan cachelagra den inre frågans resultat på avdelning för avdelning, men även i bästa fall måste den inre frågan exekveras en gång per avdelning.)
Korrelerade underfrågor kan förekomma på andra ställen förutom WHERE-satsen ; till exempel använder den här frågan en korrelerad underfråga i SELECT-satsen för att skriva ut hela listan över anställda tillsammans med den genomsnittliga lönen för varje anställds avdelning. Återigen, eftersom underfrågan är korrelerad med en kolumn i den yttre frågan, måste den köras om för varje rad i resultatet. [ citat behövs ]
VÄLJ anställd_nummer , namn , ( VÄLJ AVG ( lön ) FRÅN anställda WHERE department = emp . department ) AS department_average FROM anställda emp
Det är i allmänhet meningslöst att ha en korrelerad underfråga i FROM-satsen eftersom tabellen i FROM-satsen behövs för att utvärdera den yttre frågan, men den korrelerade underfrågan i FROM-satsen kan inte utvärderas innan den yttre frågan utvärderas, vilket orsakar en problem med kyckling och ägg . Specifikt MariaDB detta som en begränsning i sin dokumentation.
I vissa databassystem är det dock tillåtet att använda korrelerade delfrågor när man går med i FROM-satsen, hänvisar till tabellerna som listades före sammanfogningen med ett specificerat nyckelord, producerar ett antal rader i den korrelerade underfrågan och kopplar den till tabellen på vänster. Till exempel, i PostgreSQL , lägger du till nyckelordet LATERAL före den högra underfrågan, eller i Microsoft SQL Server , genom att använda nyckelordet CROSS APPLY eller OUTER APPLY istället för JOIN uppnår effekten.
En vanlig beräkningsmetod för en korrelerad delfråga är att skriva om den till en likvärdig platt fråga (en process som kallas för plattning ). Algoritmutvecklingen i denna riktning har en fördel av låg komplexitet. Eftersom detta är ett skräddarsytt tillvägagångssätt kan befintliga databassystem inte platta ut godtyckliga korrelerade underfrågor genom att följa vissa allmänna regler. Dessutom kräver detta tillvägagångssätt stora tekniska ansträngningar för att implementera utplattande algoritmer i en databasmotor. En allmän beräkningsmetod är att direkt exekvera den kapslade slingan genom att iterera alla tuplar av de korrelerade kolumnerna från det yttre frågeblocket och exekvera underfrågan lika många gånger som antalet yttre sling-tupler. Detta enkla tillvägagångssätt har en fördel av allmänt syfte eftersom det inte påverkas av typen av korrelerade operatorer eller subquery-strukturer. Den har dock en hög beräkningskomplexitet. En GPU-accelerationsmetod används för att avsevärt förbättra prestandan för den kapslade metoden med hög algoritmisk komplexitet genom att utnyttja massiv parallellism och enhetsminneslokalitet på GPU, vilket uppnår målet för både generell mjukvarudesign och -implementering och hög prestanda vid subquery-bearbetning.