Ved at vedtage god SQL-syntaks og forespørgselsskrivningspraksis vil din databaseovervågnings effektivitet forbedres og som et resultat forbedre din overordnede databaseydeevne. Der er flere gennemprøvede måder at forbedre databasens ydeevne på gennem syntaks- og forespørgselsjusteringer. Vi valgte 5 at fokusere på.
1. CASE-udtryk
Her er et par bedste fremgangsmåder til at få den bedste ydeevne fra CASE-udtryk:
- CASE-udtryk forbedrer ydeevnen ved at flytte gammel procedurekode til deklarativ kode, som derefter kan optimeres. For grundlæggende CASE-udtryk, brug
, som er det lettest optimerede. For udvidede CASE-udtryk vil hashing og andre teknikker være de mest nyttige. - Fordi NÅR klausuler testes fra venstre mod højre, er det bedst at arrangere dine klausuler, så de mest sandsynlige vises først. Dette vil skære ned på tiden brugt på unødvendig scanning.
- De fleste optimeringsværktøjer udregner også redundante tests ved at overveje rækkefølgen for udførelse. Så snart en WHEN-klausul udføres, er der ingen grund til at teste klausulen igen. Mange optimeringsværktøjer er dog ikke gode til at læse indlejrede CASE-udtryk, så det er bedst at flade dem ud til et enkelt niveau.
2. Double-dipping og vinduesklausulen
I SQL betyder "double-dipping" at besøge den samme tabel mere end én gang, hvilket gør din forespørgsel langsommere. Ideelt set prøv at få alle dine opgaver udført på et enkelt bordbesøg. Men hvis det ikke er muligt, er der et par måder at afbøde påvirkningen på ydeevnen.
Brug af midlertidige borde bygget af det samme bundbord sammenføjet er virkelig ikke den bedste måde at undgå dobbeltdykning. En bedre løsning er at bruge din SQL-motors optimering til at vise VIEWS og dele resultaterne som en arbejdstabel.
Hvis du er begrænset til en mindre end fantastisk optimering, skal du bruge midlertidige tabeller og udføre arbejdet manuelt.
Selvom ovenstående metoder er helt acceptable, er den bedste måde at undgå dobbelt-dipping på at bruge vinduesklausulen, fordi undersætningerne fungerer på samme måde som underforespørgselsfunktioner. For eksempel:
- PARTITION BY-sætningen er som en lokal GROUP BY, der deler tabellen op i grupperinger.
- ORDER BY-klausulen pålægger en sorteret rækkefølge.
- Vindusrammen (ROW eller RANGE) er som en lokal WHERE-sætning.
Du kan optimere vinduesfunktioner ved at følge disse regler:
- I indekset skal du først sortere på kolonnerne i PARTITION BY-udtrykket og derefter på de kolonner, der bruges i ORDER BY-udtrykket.
- Medtag enhver anden kolonne, der henvises til i forespørgslen, som inkluderede kolonner i indekset.
3. Brug lagrede procedurer
Objektrelationelle kortlæggere (ORM'er) forårsager adskillige præstationsproblemer, når de genererer deres egen kode. Hvis du skal bruge ORM'er, så skriv dine egne lagrede procedurer, så ydeevnen ikke lider.
Der er mange måder, hvorpå brug af lagrede procedurer forbedrer ydeevnen, herunder:
- De sender færre data på tværs af netværket, så transaktioner er hurtigere
- De muliggør kortere opkald
- Gemmede procedurer er nemmere at spore i profilværktøjer
- Fordi en lagret procedure er et faktisk objekt i din database, er det nemmere at få ydeevnestatistikker, hvilket gør det nemmere at finde ydeevneproblemer
- Genbrug af eksekveringsplan stiger
- De gør det nemmere at håndtere kantsager og tilføjer revision eller ændringslåsende adfærd
- Lagrede procedurer er ikke sårbare over for SQL-injektionsangreb
4. SLET og OPDATERING i batches
Sletning eller opdatering af en masse data fra en stor tabelscanning bruger mange ressourcer, fordi begge udsagn kører som en enkelt transaktion. Dette er en præstationsdræber, fordi hvis der opstår en fejl, mens transaktionen kører, og du skal stoppe den, skal systemet rulle hele transaktionen tilbage. At rulle tilbage store mængder data bruger masser af tid og blokerer andre transaktioner.
Du kan undgå dette ydeevneproblem ved at lave opdateringer og sletninger i små partier. Når du kører disse transaktioner i batches, hvis transaktionen bliver dræbt, er tilbagerulningen meget mindre. At rulle en lille mængde data tilbage tager ikke særlig lang tid, og andre transaktioner kan fungere, mens batchen forpligtes til disk.
5. Hent ikke flere kolonner, end du har brug for
En af hovedårsagerne til dårligt ydende forespørgsler er at hente uvedkommende kolonner. Undgå praksis, der normalt resulterer i at returnere et for stort antal kolonner. Husk følgende:
- Unødvendig brug af "SELECT *" i en forespørgsel vil sandsynligvis returnere flere kolonner, end du har brug for. Dette er spild af ressourcer og låser ressourcer fra andre brugere. Det er især vigtigt ikke tilfældigt at bruge "SELECT *" i kolonneformede SQL-databaser.
- Klip og indsæt for at genbruge kode kan resultere i uvedkommende kolonner.
- Når du starter en VIEW, kan du ende med indlejrede kolonner. Fjern forespørgsler, der yder dårligt, for at kontrollere, hvilke kolonner der er der, og slippe af med overstørrelseskolonner, du ikke har brug for. En god indikation på, at du har et problem, er, at du har en WHERE-klausul med yderligere betingelser og en FROM-klausul med yderligere outer joins.
Dette er blot nogle af de måder, hvorpå en samvittighedsfuld tilgang til SQL-syntaks og forespørgselsskrivning kan forbedre databaseovervågning. Vær ikke bange for at prøve nogle andre. En højtydende database er nøglen til at nå forretningsmål i enhver organisation.