Genom att använda bra SQL-syntax och frågeskrivningspraxis förbättras din databasövervakningseffektivitet och, som ett resultat, förbättra din totala databasprestanda. Det finns flera beprövade sätt att förbättra databasens prestanda genom syntax- och frågejusteringar. Vi valde 5 att fokusera på.
1. CASE-uttryck
Här är några bästa metoder för att få bästa resultat från CASE-uttryck:
- CASE-uttryck förbättrar prestandan genom att flytta gammal procedurkod till deklarativ kod som sedan kan optimeras. För grundläggande CASE-uttryck, använd
, som är det lättast optimerade. För utökade CASE-uttryck är hashing och andra tekniker de mest användbara. - Eftersom NÄR satser testas från vänster till höger är det bäst att ordna dina satser så att de mest troliga listas först. Detta kommer att minska tiden som läggs på onödig skanning.
- De flesta optimerare tar också bort redundanta tester genom att ta hänsyn till exekveringsordningen. Så snart en WHEN-sats körs finns det inget behov av att testa den satsen igen. Många optimerare är dock inte bra på att läsa kapslade CASE-uttryck, så det är bäst att platta ut dem till en nivå.
2. Double-dipping och fönsterklausulen
I SQL betyder "double-dipping" att du besöker samma tabell mer än en gång, vilket saktar ner din fråga. Försök helst att få alla dina jobb gjorda i ett enda bordsbesök. Men om det inte är möjligt finns det några sätt att minska effekten på prestanda.
Att använda tillfälliga bord byggda från samma basbord sammanfogade är verkligen inte det bästa sättet att undvika dubbeldoppning. En bättre lösning är att använda din SQL-motors optimerare för att visa vyer och dela resultaten som en arbetstabell.
Om du är begränsad till en mindre än stellar optimerare, använd temporära tabeller och gör jobbet manuellt.
Även om ovanstående metoder är helt acceptabla, är det bästa sättet att undvika dubbeldoppning att använda fönstersatsen eftersom underklausulerna fungerar på samma sätt som underförfrågningsfunktioner. Till exempel:
- PARTITION BY-satsen är som en lokal GROUP BY som delar upp tabellen i grupperingar.
- ORDER BY-satsen inför en sorterad ordning.
- Fönsterramen (ROW eller RANGE) är som en lokal WHERE-sats.
Du kan optimera fönsterfunktioner genom att följa dessa regler:
- Sortera först på kolumnerna i PARTITION BY-satsen i indexet och sedan på kolumnerna som används i ORDER BY-satsen.
- Inkludera alla andra kolumner som refereras till i frågan som inkluderade kolumner i indexet.
3. Använd lagrade procedurer
Objektrelationsmappare (ORM) orsakar många prestandaproblem när de genererar sin egen kod. Om du måste använda ORM, skriv dina egna lagrade procedurer så att prestandan inte blir lidande.
Det finns många sätt att använda lagrade procedurer för att förbättra prestandan, inklusive:
- De skickar mindre data över nätverket, så transaktioner går snabbare
- De möjliggör kortare samtal
- Lagrade procedurer är lättare att spåra i profilverktyg
- Eftersom en lagrad procedur är ett faktiskt objekt i din databas är det lättare att få prestandastatistik, vilket gör det lättare att hitta prestandaproblem
- Ökar återanvändning av exekveringsplan
- De gör det enklare att hantera kantfall och lägga till revision eller ändringslåsande beteende
- Lagrade procedurer är inte sårbara för SQL-injektionersattacker
4. DELETE och UPPDATERA i omgångar
Att ta bort eller uppdatera mycket data från en stor tabellsökning använder mycket resurser eftersom båda satserna körs som en enda transaktion. Detta är en prestationsdödare eftersom om ett fel uppstår medan transaktionen körs och du måste stoppa den, måste systemet återställa hela transaktionen. Att rulla tillbaka stora mängder data tar mycket tid och blockerar andra transaktioner.
Du kan undvika detta prestandaproblem genom att göra uppdateringar och raderingar i små omgångar. När du kör dessa transaktioner i omgångar, om transaktionen avbryts, är återställningen mycket mindre. Att rulla tillbaka en liten mängd data tar inte särskilt lång tid, och andra transaktioner kan fungera medan batchen binds till disken.
5. Hämta inte fler kolumner än du behöver
En av de främsta orsakerna till dåliga resultat är att hämta främmande kolumner. Undvik metoder som vanligtvis leder till att ett för stort antal kolumner returneras. Tänk på följande:
- Onödig användning av "SELECT *" i en fråga kommer sannolikt att returnera fler kolumner än du behöver. Detta är ett slöseri med resurser och låser resurser från andra användare. Det är särskilt viktigt att inte urskillningslöst använda "SELECT *" i kolumnära SQL-databaser.
- Att göra en klipp-och-klistra för att återanvända kod kan resultera i främmande kolumner.
- När du anropar en VIEW kan du få kapslade kolumner. Ta bort frågor med dåligt resultat för att kontrollera vilka kolumner som finns där och bli av med överdimensionerade kolumner som du inte behöver. En bra indikation på att du har ett problem är att du har en WHERE-sats med ytterligare villkor och en FROM-sats med ytterligare yttre kopplingar.
Det här är bara några av sätten att ta en samvetsgrann inställning till SQL-syntax och frågeskrivning kan förbättra databasövervakningen. Var inte rädd för att prova några andra. En högpresterande databas är nyckeln till att uppnå affärsmål i varje organisation.