Det er nemt at begynde at pille ved gearene til SQL-forespørgselsoptimering. Du åbner SQL Server Management Studio (SSMS), overvåger ventetiden, gennemgår udførelsesplanen, indsamler objektoplysninger og begynder at optimere SQL, indtil du kører en finjusteret maskine.
Hvis du er god nok til det, scorer du en hurtig sejr og vender tilbage til dit regelmæssigt planlagte kaos. Men hvis du justerer den forkerte ting, eller justerer den rigtige ting i den forkerte retning, ja, så gik din onsdag.
SQL-forespørgselsoptimering? Hvad får dig til at tro, at du har brug for det?
Det meste af tiden er det en stigning i problemer med billetter eller brugerklager. "Hvorfor er systemet så langsomt?" dine brugere klager. "Det tager os en evighed at køre vores sædvanlige rapporter i denne uge."
Det er selvfølgelig en ret vag beskrivelse. Det ville være rart, hvis de kunne fortælle dig, "Tingene går langsomt, fordi du har en implicit konvertering i linje 62 i CurrentOrderQuery5.sql. Kolonnen er varchar, og du passerer i et heltal." Men det er ikke sandsynligt, at dine brugere kan se det detaljeringsniveau.
Problembilletter og telefonopkald giver i det mindste en aktiv metrik:let at få øje på, let at måle. Når de begynder at rulle ind, kan du være rimelig sikker på, at det er tid til SQL-tuning.
Men der er andre, passive målinger, der gør behovet mindre klart. Ting som faldende salg, som kan skyldes en række faktorer. Er det fordi smerteligt langsomme forespørgsler i din netbutik får dine kunder til at forlade deres indkøbskurve? Er det fordi økonomien er i dårlig form?
Eller det kan være ting som træg SQL Server-ydeevne. Er det fordi en dårligt skrevet forespørgsel sender logiske læsninger gennem taget? Er det fordi serveren mangler fysiske ressourcer som hukommelse og lagerplads?
I begge scenarier kan SQL-forespørgselsoptimering hjælpe med den første mulighed, men ikke den anden.
Hvorfor anvende den rigtige løsning på det forkerte problem?
Før du går ned ad vejen til optimering, skal du sikre dig, at tuning er den rigtige løsning på det rigtige problem.
Tuning af SQL er en teknisk proces, men ethvert teknisk trin har rødder i god forretningssans. Du kunne bruge dage på at forsøge at forkorte eksekveringstiden med et par millisekunder eller reducere antallet af logiske læsninger med fem procent, men er reduktionen din tid værd? Det er rigtigt, at det er vigtigt at opfylde brugernes krav, men enhver indsats når det punkt, hvor afkastet til sidst falder.
Overvej disse SQL-forespørgselsydeevneproblemer og forretningskonteksten omkring dem:
- Acceptabel ydeevne — En forespørgsel tager 10 minutter at køre, og brugeren ønsker, at den skal køre på et minut; det virker som en rimelig forskel og et opnåeligt mål for optimering. Men hvis forespørgslen tager natten over, og brugeren tror, den skal køre på et minut, kan det være mere end et tuning-problem. For det første skal du muligvis oplyse brugeren om mængden af arbejde, som forespørgslen rent faktisk udfører. For en anden kan det være et problem med den måde, databasen blev designet på, eller den måde, klientapplikationen blev skrevet på.
- Hjælpe — Antag, at du er ansvarlig for at administrere den økonomiske database i en produktionsvirksomhed. I slutningen af hver måned klager brugerne over dårlig ydeevne. Du sporer problemet til en række månedsafslutningsrapporter, der drives af Accounting, som hver tager timer og går direkte ind i et arkivskab, der ikke er undersøgt af nogen. I stedet for at tune forklarer du problemet til virksomhedslederne og får tilladelse til at slette rapporterne.
- Tidsskift — Eller antag, at de samme rapporter er vigtige for ledelsen, men ikke presserende for virksomheden. Hvis de køres en gang om ugen eller om måneden, kan de planlægges til off-peak timer ved at pre-cache datasættet og sende resultaterne til en fil. Det fjerner flaskehalsen på de andre forretningsbrugere og frigør regnskabsbrugeren fra at skulle vente på rapporterne.
Når du inddrager forretningskontekst i din beslutning om at optimere, kan du sætte prioriteter og købe dig tid.
Når du optimerer SQL-forespørgsler, så prøv SQL-diagrammer
SSMS og værktøjerne indbygget i SQL Server tilbyder det meste af det, du har brug for til effektiv SQL-forespørgselsoptimering. Kombiner værktøjerne med en metodisk tilgang omkring de følgende trin, som beskrevet i e-bogen "Den grundlæggende guide til SQL-forespørgselsoptimering":
- Overvåg ventetid
- Gennemgå eksekveringsplanen
- Samle objektoplysninger
- Find kørebordet
- Identificer præstationsinhibitorer
I trin 4 er dit mål at drive forespørgslen med den tabel, der returnerer færrest data. Når du studerer joinforbindelser og prædikater og filtrerer tidligere i forespørgslen i stedet for senere, reducerer du antallet af logiske læsninger. Det er et stort skridt i SQL-forespørgselsoptimering.
SQL-diagrammer er en grafisk teknik til at kortlægge mængden af data i tabellerne og finde ud af, hvilket filter der returnerer færrest poster. Først bestemmer du, hvilke tabeller der indeholder de detaljerede oplysninger, og hvilke tabeller der er master- eller opslagstabeller. Overvej det enkle eksempel på denne forespørgsel mod en universitetsregistreringsdatabase:
Detaljetabellen er registrering. Den har to opslagstabeller, elev og klasse. For at diagramme disse tabeller skal du tegne et træ på hovedet, der forbinder detaljetabellen (øverst) med pile (eller links) til opslagstabellerne, sådan her:
Beregn nu det relative antal poster, der kræves til joinkriterierne (det vil sige det gennemsnitlige forhold mellem rækker, der er relateret mellem detaljetabellen og opslagstabeller). Skriv tallene i hver ende af pilen. I dette eksempel er der for hver elev omkring 5 poster i registreringstabellen, og for hver klasse er der omkring 30 poster i registrering. Det betyder, at det aldrig burde være nødvendigt at JOINDE mere end 150 (5×30) poster for at få et resultat for en enkelt elev eller en enkelt klasse.
Denne øvelse er nyttig, hvis dine joinkolonner ikke er indekseret, eller hvis du ikke er sikker på, at de er indekseret.
Dernæst skal du se på filtreringsprædikaterne for at finde ud af, hvilken tabel du skal drive forespørgslen med. Denne forespørgsel havde to filtre:et ved registrering annulleret ='N' og det andet på signup_date mellem to datoer. For at se, hvor selektivt filteret er, skal du køre denne forespørgsel ved registrering:
vælg antal(1) fra registreringen, hvor annulleret ='N'
OG r.signup_date MELLEM :beg_date OG :beg_date +1
Det returnerer 4.344 poster ud af de 79.800 samlede registreringer i registreringen. Det vil sige, at 5,43 procent af posterne vil blive læst med det filter.
Det andet filter er på klasse:
vælg antal(1) fra klasse, hvor navn ='ENGELSK 101'
Det returnerer to poster ud af 1.000 eller 0,2 procent, hvilket repræsenterer et meget mere selektivt filter. Klassen er således kørebordet, og den, som du først skal fokusere din SQL-tuning på.
Brugerens stemme
Hvis du er sikker på, at du har brug for SQL-tuning, giver "Den grundlæggende guide til SQL-forespørgselsoptimering" yderligere indsigt. Den leder dig gennem fem tip til justering af ydeevne med copy-and-paste-forespørgsler og casestudier, inklusive den, der er beskrevet ovenfor.
Du vil sandsynligvis opdage, at det vigtigste værktøj til optimering af SQL-forespørgsler er brugerens stemme. Hvorfor? Fordi den stemme fortæller dig, hvornår du skal begynde at optimere, og den fortæller dig, hvornår du har optimeret nok. Det kan sikre, at du begynder at pille ved gearene, når du har brug for det, og stopper, mens du stadig er foran.