Det är lätt att börja mixtra med redskapen för SQL-frågeoptimering. Du öppnar SQL Server Management Studio (SSMS), övervakar väntetiden, granskar exekveringsplanen, samlar in objektinformation och börjar optimera SQL tills du kör en finjusterad maskin.
Om du är tillräckligt bra på det gör du en snabb seger och återgår till ditt regelbundna kaos. Men om du justerar fel sak, eller justerar rätt sak i fel riktning, ja, där gick din onsdag.
SQL-frågeoptimering? Vad får dig att tro att du behöver det?
För det mesta är det en ökning av problembiljetter eller användarklagomål. "Varför är systemet så långsamt?" dina användare klagar. "Det tar en evighet för oss att köra våra vanliga rapporter den här veckan."
Det är förstås en ganska vag beskrivning. Det skulle vara trevligt om de kunde berätta för dig, "Saker och ting går långsamt eftersom du har en implicit konvertering i rad 62 i CurrentOrderQuery5.sql. Kolumnen är varchar och du passerar i ett heltal." Men det är inte troligt att dina användare kan se den detaljnivån.
Åtminstone ger problembiljetter och telefonsamtal ett aktivt mätvärde:lätt att upptäcka, lätt att mäta. När de börjar rulla in kan du vara ganska säker på att det är dags för SQL-justering.
Men det finns andra, passiva mått som gör behovet mindre tydligt. Saker som fallande försäljning, vilket kan bero på hur många faktorer som helst. Är det för att smärtsamt långsamma frågor i din webbutik får dina kunder att överge sina kundvagnar? Är det för att ekonomin är i dåligt skick?
Eller det kan vara saker som trög SQL Server-prestanda. Är det för att en dåligt skriven fråga skickar logiska läsningar genom taket? Är det för att servern har ont om fysiska resurser som minne och lagring?
I båda scenarierna kan SQL-frågeoptimering hjälpa med det första alternativet, men inte det andra.
Varför tillämpa rätt lösning på fel problem?
Innan du går in på optimeringsvägen, se till att inställning är rätt lösning på rätt problem.
Att trimma SQL är en teknisk process, men varje tekniskt steg har rötter i affärsmässighet. Du kan ägna dagar åt att försöka förkorta exekveringstiden med några millisekunder eller minska antalet logiska läsningar med fem procent, men är minskningen värd din tid? Det är sant att det är viktigt att uppfylla användarnas krav, men alla ansträngningar når så småningom att avkastningen minskar.
Tänk på dessa SQL-frågeprestandaproblem och affärssammanhanget runt dem:
- Acceptabel prestanda — En fråga tar 10 minuter att köra och användaren vill att den ska köras på en minut; det verkar vara en rimlig skillnad och ett uppnåeligt mål för optimering. Men om frågan tar över en natt och användaren tror att den ska köras på en minut, kan det vara mer än ett inställningsproblem. För det första kan du behöva utbilda användaren om hur mycket arbete frågan faktiskt utför. För en annan kan det vara ett problem med hur databasen utformades eller hur klientapplikationen skrevs.
- Verktyg — Anta att du är ansvarig för att administrera den finansiella databasen i ett tillverkningsföretag. I slutet av varje månad klagar användare över dålig prestanda. Du spårar problemet till en serie månadsslutsrapporter som drivs av Accounting som tar timmar var och en och går direkt in i ett arkivskåp som inte granskas av någon. Istället för att trimma förklarar du problemet för verksamhetscheferna och får tillstånd att radera rapporterna.
- Tidsförskjutning — Eller anta att samma rapporter är viktiga för styrningen men inte brådskande för verksamheten. Om de körs en gång i veckan eller per månad kan de schemaläggas för lågtrafik genom att förcacha datamängden och skicka resultaten till en fil. Det tar bort flaskhalsen för andra företagsanvändare och befriar redovisningsanvändaren från att behöva vänta på rapporterna.
När du tar med affärssammanhang i ditt beslut att optimera kan du prioritera och köpa tid.
När du optimerar SQL-frågor, prova SQL-diagrammet
SSMS och verktygen som är inbyggda i SQL Server erbjuder det mesta du behöver för effektiv SQL-frågeoptimering. Kombinera verktygen med ett metodiskt tillvägagångssätt kring följande steg, som beskrivs i e-boken "The fundamental guide to SQL query optimization":
- Övervaka väntetid
- Granska exekveringsplanen
- Samla objektinformation
- Hitta körtabellen
- Identifiera prestationshämmare
I steg 4 är ditt mål att driva frågan med den tabell som returnerar minst data. När du studerar kopplingar och predikat och filtrerar tidigare i frågan snarare än senare, minskar du antalet logiska läsningar. Det är ett stort steg i SQL-frågeoptimering.
SQL-diagrammet är en grafisk teknik för att kartlägga mängden data i tabellerna och hitta vilket filter som returnerar minst poster. Först bestämmer du vilka tabeller som innehåller den detaljerade informationen och vilka tabeller som är huvud- eller uppslagstabeller. Tänk på det enkla exemplet på den här frågan mot en universitetsregistreringsdatabas:
Detaljtabellen är registrering. Den har två uppslagstabeller, elev och klass. För att diagramma dessa tabeller, rita ett upp och ner träd som förbinder detaljtabellen (överst) med pilar (eller länkar) till uppslagstabellerna, så här:
Beräkna nu det relativa antalet poster som krävs för kopplingskriterierna (det vill säga det genomsnittliga förhållandet av rader relaterade mellan detaljtabellen och uppslagstabellerna). Skriv siffrorna i varje ände av pilen. I det här exemplet finns det cirka 5 poster i registreringstabellen för varje elev, och för varje klass finns det cirka 30 poster i registreringen. Det betyder att det aldrig borde vara nödvändigt att GÅ MED till mer än 150 (5×30) poster för att få ett resultat för en enskild elev eller en klass.
Den övningen är användbar om dina kopplingskolumner inte är indexerade eller om du inte är säker på att de är indexerade.
Titta sedan på filtreringspredikaten för att hitta vilken tabell du ska driva frågan med. Den här frågan hade två filter:ett vid registrering avbröts ='N' och det andra på signup_date mellan två datum. För att se hur selektivt filtret är, kör den här frågan vid registrering:
välj count(1) från registreringen där annullerad ='N'
OCH r.signup_date MELLAN :beg_date OCH :beg_date +1
Den returnerar 4 344 poster av de 79 800 totala registreringarna. Det vill säga, 5,43 procent av posterna kommer att läsas med det filtret.
Det andra filtret är på klass:
välj count(1) från klass där namn ='ENGLISH 101'
Den returnerar två poster av 1 000, eller 0,2 procent, vilket representerar ett mycket mer selektivt filter. Klass är alltså drivbordet och den som du ska fokusera din SQL-inställning på först.
Användarens röst
Om du är säker på att du behöver SQL-justering ger "Den grundläggande guiden till SQL-frågeoptimering" ytterligare insikter. Den leder dig genom fem prestandajusteringstips med kopiera-och-klistra-frågor och fallstudier, inklusive den som beskrivs ovan.
Du kommer förmodligen att upptäcka att det enskilt viktigaste verktyget för SQL-frågeoptimering är användarens röst. Varför? För den rösten låter dig veta när du ska börja optimera och den talar om för dig när du har optimerat tillräckligt. Det kan se till att du börjar mixtra med växlarna när du behöver och stannar medan du fortfarande är före.