Det opfordres altid til, når du skriver forespørgsler eller SQL Server-databasekode (procedurer og visninger), at tage hensyn til eksekveringsplanen. Det er der flere grunde til. For det første - optimeringsværktøjet vælger måske en plan, som du ikke forventer. For eksempel indeksscanning af en stor tabel, før den matches med en mindre tabel. For det andet – der bør tages hensyn til, hvordan denne forespørgsel vil fungere i måneder eller år fremover, hvis forespørgslerne kører i et nyt system med små tabeller, som vil vokse. Og endelig, men vigtigst af alt, hvor hurtig er denne forespørgsel, og hvor mange ressourcer bruger den. Det sidste punkt virker måske ikke så vigtigt, tænker du måske, så længe det tager mindre end 3 sekunder, det er godt nok, men hvis det kunne køre på <1 sek, ville det ikke være bedre? Hvis dine databaser er cloud-hostet, kan reduktion af ressourcer også spare dig penge.
Mange tilfælde for SQL-optimering kommer normalt fra et problem, som er opdaget af slutbrugeren eller din overvågningssoftware. "Hvorfor tager denne rapport 30 minutter at generere?", "Hvad forårsager den stigning i I/O-venten" eller "Hvorfor tager disse job dobbelt så lang tid at køre, som de gjorde sidste år?"
I alle disse scenarier handler det stadig om en vis viden om eksekveringsplaner og den bedste måde at rette SQL'en på for at forbedre situationen, og dette kan være meget tidskrævende og ikke altid vellykket.
Lad os tage et eksempel. Så du skriver en ny forespørgsel, udfører den og tænker så, åh, det tager for lang tid.
17 sekunder for 730 rækker, hvad skal jeg gøre?
Lad os først gennemgå udførelsesplanen:
Dette er ikke altid ligetil, hvis du skal zoome ind og ud for at få mening ud af det. Så det første råd er at få en god planviser som denne med Spotlight Tuning Pack.
Planfremviseren fremhæver de vigtigste informationer, vi har brug for, og hvor de vigtigste handlinger er, samt fremhæver eventuelle advarsler.
Her er et eksempel:
Så der er et problem med denne kode, men hvad kan vi gøre ved det?
Nå, faktisk ret meget. Vi kunne bruge forespørgselstip, se på at tilføje nogle indekser (glem ikke, at dette kan påvirke andre forespørgsler og DML), tilføje kodestykker, der ikke ændrer resultatsættet, men som påvirker optimeringsværktøjet til at generere en anden plan og små tricks til stop optimizeren i betragtning af et bestemt indeks, den bruger, og generer måske en ny plan. Men dette er alt sammen forsøg og fejl og meget tidskrævende at gøre manuelt.
Ved at tilføje Spotlight Extensions-applikationen til SSMS og abonnere på Spotlight Tuning Pack kan vi lade optimeringsfunktionen i Tuning Pack gøre alt det hårde arbejde for os.
Du har måske bemærket på det første skærmbillede, at når funktionen er aktiveret, registrerer den automatisk, at optimering er mulig:
Klik på Vis analyse
Du kan derefter klikke på knappen Optimer, og optimeringsmotoren vil analysere koden og begynde at anvende omskrivningsregler, der vil ændre syntaksen for SQL'en, der giver alternativer, der giver det samme resultatsæt, og derefter teste dem, så vi kan se, om der er alternativ udførelse planer er hurtigere og hvorfor. Reglerne anvendes i kombinationer, så de mulige alternativer kan være over 100. Værktøjet viser dig dog kun alternativer, der er hurtigere end originalen.
Denne proces kører i baggrunden og sparer dig enormt meget tid, hvis du forsøgte at gøre dette manuelt.
Og når resultaterne vises, kan du sammenligne alternativerne, se kodeforskellene, sammenligne planerne og gennemgå statistikken.
Så tilbage til SSMS med min nye version af forespørgslen og test det af.
Succes.
Hvis dette er i et udviklingsmiljø, kan du overveje at tømme buffercachen ved hjælp af DBCC DROPCLEANBUFFERS for at teste dine forespørgsler med en kold buffercache uden at lukke ned og genstarte serveren.
Overvej også at tilføje SET STATISTICS IO ON til forespørgslen for at få flere oplysninger om, hvorfor forespørgselssyntaksen gjorde en forskel:
Original:
Omskriv:
Og dette kan også opnås i Tuning Pack med statistiksammenligningsfunktionen:
Så med den vellykkede ændring og glade slutbruger, gå videre til næste forespørgsel. Ved løbende at forbedre ydeevnen af individuelle forespørgsler forbedrer vi forekomstens ydeevne.