Merge Join ?

Ofta består vårt arbete på SQL Service av att hjälpa våra kunder med felsökning och prestandaoptimering av befintlig kod. En bra sätt är då att titta på antalet läsningar och ställa det i relation till det antal rader som blir resultatet av en fråga. För en tid sedan upptäckte jag hos en kund dessa siffror på en fråga som bara genererade ett resultat på några rader. Dessutom var den här frågan central i hela applikationen och därmed flitig använd. Table ‘table1’. Scan count 35786, logical reads 108733 Table ‘table2’. Scan count 2, logical reads 71463 SQL Server Execution Times: CPU time = 3219 ms, elapsed time = 4167 ms. Vad var då problemet ? I den genererade koden hade man använt en sk Query join hints och just i det här fallet Merge Join.

Om man i stället låter optimizern’n skapa en optimal exekveringsplan genom att ta bort Merge Join så får minskar antalet läsningar rätt dramatiskt. Table ‘table1’. Scan count 1, logical reads 924 Table ‘table2’. Scan count 4, logical reads 8 SQL Server Execution Times: CPU time = 609 ms, elapsed time = 623 ms. Som ni ser blir det en avsevärd skillnad i antalet läsningar som innebär att svarstiderna sjunker rätt rejält. Tyvärr var den här koden inbyggd i applikationen och inte enligt best practice i en stored procedure.

Detta gjorde att en ny version av applikationen måste byggas och på det den vanliga testproceduren med det antal resuser som krävs för testning innan detta kunde produktionssättas och användarna slapp extra svarstider på 3-4 sekunder. Slutsatsen för detta enkla exempel blir alltså :

– Använd stored procedures så blir allt mycket enklare att underhålla plus alla andra fördelar som det ger.
– Använd inte Query join hints, och om man ändå gör det så måste man veta vad man gör och också bevaka t.ex. svarstider när datamängderna ändras.