Hvorfor er det vigtigt at du bruger 5-10 minutter ekstra på at optimere dine SQL Query?
Alle de SQL-forespørgsler vi skriver mod databasen trækker på det samme hardware, og ja, det er rigtigt hardware er efterhånden blevet helt utrolig kraftigt, så når vores server begynder at blive langsom så kan vi sagtens smide endnu hurtigere diske og mere ram i dem og så kører det hele igen. Men hvad hvis vi i stedet for kiggede på de SQL Query der sendes afsted mod serveren og ser om de kan optimeres – og det er der sikkert nogle der kan. Når SQL Query er optimeret eksekveres de hurtigere, de blokerer derved i kortere tid for andre forespørgsler og serveren vil begynde at føles hurtigere for alle der benytter den. Som sidegevinst har vi ikke den ekstra store udgift til hardware, DERFOR skal vi bruge den ekstra tid på at sikre at vores SQL Query performer optimalt.
Vi kender formentlig alle sammen godt til at man bare lige skal skrive en hurtig SQL forespørgsel til en rapport, ledelsen har efterspurgt. Den skal kun bruges få gange, så vi kaster noget hurtig SQL sammen og leverer resultatet. Vi tænker ikke i performance for det er jo kun få gange den skal bruges, og pludseligt 2 år senere er det blevet en vital rapport for forretningen. Men SQL Query er stadig den samme kode som vi lavede for 2 år siden og rapporten er lang tid om at blive beregnet færdig, eller vi har glemt at rette den SELECT * til som vi ”testede” af i produktionsmiljøet (fy* test i produktionsmiljøet.. men det ser vi 😊) og som nu bruges af vores udviklere, der selv filtrerer data fra i deres applikationer.
Dette er blot få eksempler fra virkeligheden, heldigvis findes der flere eksempler på værktøjer og SQL forespørgsler du kan bruge for at finde de mest ”krævende” SQL Query på serveren. Brent Ozar’s team har et script der kan hjælpe – det er gratis og ret godt, du kan også selv skrive en forespørgslen mod nogle af SQL Serverens DMV’er som eks. denne:
Du kan nu tage fat i resultatsættet og analysere hvilke SQL Query du skal kigge på, men husk ”Der er ALTID en top 10” det vil sige at bare fordi serveren viser disse forespørgsler som de mest krævende, er det ikke ensbetydende med at de skal rettes, SQL Query kan godt være helt optimeret, det bruges bare så meget at det ligger i top 10.
Et vigtigt værktøj i din optimering af SQL Query er executionplans i SQL Manegment Studio (SSMS), her kan du få et overblik over hvordan SQL Serverens query optimizer er kommet frem til at eksekvere din SQL Query så resultatet kommer hurtigst muligt/kræver færrest ressourcer.
Når du går i gang med at analysere dine SQL Queries er her et par råd:
- Undgå så vidt muligt at bruge funktioner i din Where clause
- Undgå implicit konvertering (eks. Where Tal = ’Tekst’)
- Minimer dit resultatsæt så tidligt som muligt i din SQL Query, f.eks. ved at lave et temp tabel (husk du kan godt lave index på temp tabeller)
- Og kend dine data, du skal have styr på index, hvordan data bruges og sørge for at statistics bliver vedligeholdt
Prøv at forestille dig at du får optimeret en SQL Query med 200% som f.eks. bruges hvert 5. minut, det er utrolig tilfredsstillende, og godt for dit SQL miljø som jo typisk har mange samtidige brugere, der alle vil have data hurtigst muligt og helst i går.
Ovenstående emner med mere bliver præsenteret på vores 1 dags kursus i SQL Query performance tuning den 12/9-2018 her vil du få en introduktion til executionplans, en kort gennemgang af hvordan SQL Serveren forsøger at finde den bedste plan, nogle gode råd til hvad du skal undgå, samt nogle værktøjer så du kommer godt i gang med SQL Query optimering. Det er et begynder kursus, men henvender sig til alle, der gerne vil i gang med at forstå executionplans samt Query tuning.
Målet er at du får lysten og nogle værktøjer så du kan komme i gang med at optimere jeres SQL miljø uden det nødvendigvis betyder køb af ny hardware – Jeg håber vi ses.
Skulle du sidde med SQL udfordringer så er jeg samt mine dygtige kollegaer i Unit IT klar til at hjælpe, du er altid velkommen til at ringe til os på 88 333 333.
