YTELSE FOR SQL-Spørring
I dette tilfellet vil du ikke merke en stor forskjell fordi 30 000 rader ikke er for vanskelig for databasen å behandle. Men hvis du snakket om hundrevis av millioner av rader eller mer, vil du se en merkbar forbedring ved å samle før du blir med. Når du gjør dette, må du sørge for at det du gjør er logisk konsistent-du bør bekymre deg for nøyaktigheten av arbeidet ditt før du bekymrer deg for kjørehastighet.
13 YTELSESTIPS FOR SPØRRING
Husk å prefiks objektnavn (dvs. tabell, lagret prosedyre, visning) med eier / skjemanavn.
Årsak: HVIS eier – /skjemanavnet ikke oppgis, PRØVER SQL Server-motoren å finne det i alle skjemaer til objektet finner det. SQL Server engine vil ikke søke etter tabellen utenfor sin eier / skjema hvis eier/skjema navn er gitt.
Operatoren *
ikke bruk operatoren * i SELECT-setningene dine. Bruk i stedet kolonnenavn.
Årsak: SQL Server søker etter alle kolonnenavn og erstatter * med alle kolonnenavn på tabellen (e) i SQL SELECT-setningen. Å gi kolonnenavn unngår dette søk-og-erstatt og forbedrer ytelsen.
Nullable Kolonner
Unngå Å bruke IKKE I når du sammenligner med nullable kolonner. Bruk EKSISTERER ikke i stedet.
Årsak: NÅR IKKE I brukes i spørringen (selv om spørringen ikke returnerer rader med nullverdier), VIL SQL Server kontrollere hvert resultat for å se om det er null eller ikke. Bruke IKKE EKSISTERER vil ikke gjøre sammenligningen med nulls. OGSÅ, IKKE EKSISTERER returnerer bare to stater (sant eller usant), MENS IKKE I kan returnere opptil tre stater (sant, usant, NULL) og kan ikke gi deg resultatet du forventet.
Tabellvariabler Og Koblinger
Unngå å bruke tabellvariabler i koblinger. Bruk midlertidige tabeller, Cte-Er (Vanlige Tabelluttrykk) eller avledede tabeller i sammenføyninger i stedet.
Årsak: selv om tabellvariabler er svært raske og effektive i mange situasjoner, SER SQL Server-motoren det som en enkelt rad. PÅ grunn AV DENNE grunn VIL SQL produsere en utførelsesplan som vil utføre forferdelig når den brukes i sammenføyninger.
Navn På Lagrede Prosedyrer
ikke start navnet på lagrede prosedyrer med sp_.
Årsak: når den lagrede prosedyren heter sp_ ELLER SP_, KONTROLLERER SQL Server alltid i system – / hoveddatabasen selv om eier – / skjemanavnet er angitt. Å gi et navn uten SP_ til en lagret prosedyre unngår denne unødvendige kontrollen i system / master-databasen I SQL Server.
Bruk SET NOCOUNT på
Bruk SET NOCOUNT PÅ med dml-operasjoner.
Årsak: når du utfører dml-operasjoner (dvs. SETT INN, SLETT, VELG OG OPPDATER) RETURNERER SQL Server alltid antall berørte rader. I komplekse spørringer med mange sammenføyninger blir dette et stort ytelsesproblem. Bruke SET NOCOUNT PÅ vil forbedre ytelsen fordi det ikke vil holde styr på antall rader berørt.
Unngå Å Bruke GRUPPE ETTER, REKKEFØLGE ETTER og DISTINKT
Unngå Å bruke GRUPPE ETTER, REKKEFØLGE ETTER og DISTINKT når det er mulig.
Årsak: NÅR DU bruker GRUPPE ETTER, REKKEFØLGE ETTER ELLER DISTINKT, OPPRETTER SQL Server-motoren en arbeidsbord og legger dataene i arbeidsbordet. Deretter organiserer den disse dataene i arbeidstabellen som forespurt av spørringen, og returnerer det endelige resultatet.
Kontroller Indekser
det skal være indekser på alle felt som brukes I WHERE og JOIN-deler AV SQL-setningen.
Årsak: NÅR felt ikke indekseres, GJØR SQL Server vanligvis en fullstendig tabellskanning, og dette kan redusere ytelsen. Med mindre tabellen er svært liten, en tabell scan tendens til å gi den verste ytelsen ut av alle typer database leser.
Bruk Samme Datatype PÅ JOIN og Hvor Klausuler
dette er lettere sagt enn gjort, avhengig av dine tillatelser til å gjøre endringer i skjemaet.
Årsak: NÅR du kobler sammen eller sammenligner to felt med forskjellige datatyper, MÅ SQL gjøre en konvertering av feltet før det kan gjøre en sammenligning, selv om feltene er indeksert. Hvis feilaktige datatyper er uunngåelig, kan du prøve å kaste den større datatypen til den mindre datatypen når det er mulig.
Unngå Å Bruke Beregnede Felt I SAMMENFØYNING og Hvor Klausuler
dette kan gjøres ved å opprette et felt med de beregnede verdiene som brukes i sammenføyning på tabellen. Se nedenfor.