Det uppmuntras alltid när du skriver frågor eller SQL Server-databaskod (procedurer och vyer) att ta hänsyn till exekveringsplanen. Det finns flera anledningar till detta. För det första - optimeraren kanske väljer en plan som du inte förväntar dig. Till exempel genom att indexera en stor tabell innan den matchas med en mindre tabell. För det andra – hänsyn bör tas till hur denna fråga kommer att fungera under månader eller år framöver om frågorna körs i ett nytt system med små tabeller som kommer att växa. Och slutligen men viktigast av allt, hur snabb är den här frågan och hur mycket resurser använder den. Den sista punkten kanske inte verkar så viktig, du kanske tänker så länge det tar mindre än 3 sekunder som är bra nog, men om det kunde köras på <1 sek skulle det inte vara bättre? Om dina databaser är värdbaserade i moln kan minskade resurser också spara pengar.
Många fall för SQL-optimering kommer normalt från ett problem som upptäcks av slutanvändaren eller din övervakningsprogramvara. "Varför tar den här rapporten 30 minuter att generera?", "Vad är det som orsakar den här ökningen i I/O-väntetiden" eller "Varför tar dessa jobb dubbelt så lång tid att köra som de gjorde förra året?"
I alla dessa scenarier handlar det fortfarande om viss kunskap om exekveringsplaner och det bästa sättet att fixa SQL för att förbättra situationen och detta kan vara mycket tidskrävande och inte alltid framgångsrikt.
Låt oss ta ett exempel. Så du skriver en ny fråga, kör den och tänker sedan, herregud, det här tar för lång tid.
17 sekunder för 730 rader, vad ska jag göra?
Låt oss först granska genomförandeplanen:
Det här är inte alltid direkt om du måste zooma in och ut för att förstå det. Så det första rådet är att skaffa en bra planvisare som den här med Spotlight Tuning Pack.
Planvisaren lyfter fram de viktigaste informationsbitarna vi behöver och var huvudoperationerna är samt markerar eventuella varningar.
Här är ett exempel:
Så det finns ett problem med den här koden, men vad kan vi göra åt det?
Tja, faktiskt ganska mycket. Vi kan använda frågetips, titta på att lägga till några index (glöm inte att detta kan påverka andra frågor och DML), lägga till kodbitar som inte ändrar resultatuppsättningen men påverkar optimeraren att generera en annan plan och små knep för att stoppa optimeraren med tanke på ett visst index som den använder och kanske generera en ny plan. Men allt detta är trial and error och mycket tidskrävande att göra manuellt.
Genom att lägga till Spotlight Extensions-applikationen till SSMS och prenumerera på Spotlight Tuning Pack kan vi låta optimeringsfunktionen i Tuning Pack göra allt det hårda arbetet åt oss.
Du kanske har märkt i den första skärmdumpen att när funktionen är aktiverad känner den automatiskt av att optimering är möjlig:
Klicka på Visa analys
Du kan sedan klicka på knappen Optimera och optimeringsmotorn kommer att analysera koden och börja tillämpa omskrivningsregler som kommer att ändra syntaxen för SQL som ger alternativ som ger samma resultatuppsättning, och sedan testa dem så att vi kan se om någon alternativ exekvering planerna är snabbare och varför. Reglerna tillämpas i kombinationer så att de möjliga alternativen kan vara över 100. Verktyget visar dock bara alternativ som är snabbare än originalet.
Den här processen körs i bakgrunden och sparar enormt mycket tid om du försökte göra detta manuellt.
Och när resultaten visas kan du jämföra alternativen, se kodskillnaderna, jämföra planerna och granska statistiken.
Så tillbaka till SSMS med min nya version av frågan och testa den.
Framgång.
Om detta är i en utvecklingsmiljö kan du överväga att tömma buffertcachen med DBCC DROPCLEANBUFFERS, för att testa dina frågor med en kall buffertcache utan att stänga av och starta om servern.
Överväg också att lägga till SET STATISTICS IO ON i frågan för mer information om varför frågesyntaxen gjorde skillnad:
Original:
Skriv om:
Och detta kan också uppnås i Tuning Pack med funktionen för statistikjämförelse:
Så, med den lyckade förändringen och nöjda slutanvändare, gå vidare till nästa fråga. Genom att ständigt förbättra prestanda för enskilda frågor förbättrar vi prestandan för instansen.