Snabba upp SELECT DISTINCT
Förord
Innehåll
Snabba upp dina SELECT DISTINCT satser
av Neil Boyle
Många människor använder DISTINCT i sin SELECT-sats då de vill filtrera bort dubblett data från poster som en SQL-sats har tagit fram.
Se t ex på den här SQL-satsen från en PUBS databas:
SELECT DISTINCT au_fname, au_lname FROM authors
Då du ska göra en simpel SELECT från en tabell (som den ovan) så är ovanstående exempel det snabbaste och enklaste sättet att göra det på.
Om du däremot vill skapa en mer komplicerad SQL-sats så bör du skriva den på ett sånt sätt så att du kan få ett övertag över prestandan. Följande SQL-sats returnerar bara författare som redan har publicerat en bok:
SELECT DISTINCT au_fname, au_lname
FROM authors a JOIN titleAuthor t
ON t.au_ID = a.au_ID
I ovanstående sats kommer vi bara att få fram unika namn på författare som har skrivit någon bok. Den satsen fungerar som den ska, men vi kan tjäna lite extra prestanda genom att göra om den till följande SQL-sats:
SELECT au_fname, au_lname
FROM authors a
WHERE EXISTS (SELECT * FROM titleAuthor t WHERE t.au_ID = a.au_ID)
Anledningen till att den andra SQL-satsen går lite snabbare är för att EXISTS klausulen returnerar en författare då första boken från denne hittas. Därefter bryr den sig inte längre om att få fram fler böcker från samma författare (vi har redan fått fram författarens namn och vi vill bara se den en gång).
När du använder DISTINCT satsen så returnerar satsen en kopia av författares namn för varje bok denne har skrivit. Listan på författare genererar då ett behov av att undersökas vidare, så att kopiorna tas bort enligt DISTINCT satsens önskemål.
Du kan undersöka exekveringsplanen för varje SQL-sats för att komma fram till vart förbättringarna i prestandan ligger. I SQL 6.5 kan du t ex se att ett steg som involverar en Worktable används för DISTINCT satsen, men inte för EXISTS satsen. I SQL 7.0 och 2000 kan du generera en grafisk exekveringsplan, för att du ska kunna jämföra dem lättare.
Vilka förbättringar av prestanda du kan få beror på andelen matchande poster i de högra och vänstra (eller inre och yttre) tabellerna. SQL-satserna nedan fungerar i vilken SQL databas som helst. Klistra in de två satserna i ISQL eller i Query Optimizer, och jämför exekveringsplanen och I/O lasten som de producerar i olika databaser. Den nedre av satserna kommer förmodligen att visa sig mest effektiv, även fast mängden prestandas som du tjänar kan variera.
SELECT DISTINCT o.name FROM sysobjects o
JOIN sysindexes I ON o.id = i.id
WHERE o.type = 'U'
SELECT o.name FROM sysobjects o
WHERE o.type = 'U'
AND EXISTS (SELECT 1 FROM sysindexes I WHERE o.id = i.id)
Du måste förstå hur relationerna ser ut mellan två (eller fler) tabeller när du använder JOIN, för att kunna utföra det här testet korrekt. De två frågorna från en Northwind databas du ser nedan är designade till att returnera customerID, vilka har fått högre rabatt än 2 % på någon vara. Vid en första titt så kan man tro att de båda satserna genererar samma resultat, bara för att de följer formatet i exemplen ovan. Men så är det faktiskt inte.
SELECT DISTINCT customerID FROM orders o
JOIN [order details] od
ON o.OrderID = od.OrderID
WHERE discount > 0.02
SELECT customerID FROM orders o
WHERE EXISTS (
SELECT *
FROM [order details] od
WHERE o.OrderID = od.OrderID
AND discount > 0.02)
Dessa två satser möter inte förväntningarna, därför att det är OrderID, och inte kundnamnet, som definierar relationerna mellan två tabeller. Den nedre av satserna kommer att returnera flertalet kundnamn, ett för varje order som kunden har gjort. För att se det så kan du prova att lägga in OrderID kolumnen i SELECT listan.
Nästa gång som du tänker använda SELECT DISTINCT, ta en stund och tänk igenom om det skulle gå att skriva om satsen för att förbättra dess prestanda. Du kan bli överraskad när du ser vad en liten redigering i koden kan göra för din applikation.
0 Kommentarer