SQL-serverindeksoversigt
Når man taler om justering af SQL Server-ydelse og forbedring af forespørgsler, er den første ting at overveje SQL Server-indekset. Det tjener til at fremskynde læsning af data fra underliggende tabeller ved at give hurtig adgang til de anmodede rækker. Den behøver således ikke at scanne alle tabellens poster.
SQL Server-indekset giver disse hurtige søgemuligheder på grund af indeksets B-Tree-struktur. Denne struktur gør det muligt hurtigt at bevæge sig gennem tabelrækkerne baseret på indeksnøglen og hente de ønskede poster på én gang. Det behøver ikke at læse hele tabellen.
SQL Server-indekseringstyper
Blandt hovedtyperne er vi opmærksomme på de klyngede og ikke-klyngede indekser.
Det Klyngede indeks sorterer de faktiske data på datasiderne i henhold til de klyngede indeksnøgleværdier. Det gemmer dataene på "blad"-niveauet af indekset, hvilket sikrer muligheden for kun at oprette ét klynget indeks på hver tabel. Det klyngede indeks oprettes automatisk, når en primærnøglebegrænsning vises på heaptabellen.
Det Ikke-klyngede indeks indeholder indeksnøgleværdien og en pegepind til resten af rækkekolonnerne i hovedtabellen. Det er "blad"-niveauet for indekset, med mulighed for at oprette op til 999 ikke-klyngede indekser på hver tabel.
Hvis din tabel ikke har noget klynget indeks oprettet på sig, kaldes tabellen 'Heap-tabellen'. En sådan tabel har ingen kriterier til at specificere datarækkefølgen inde i siderne og sidernes sortering og sammenkobling.
Når der oprettes et klynget indeks på den tabel, kalder vi den sorterede tabel for en klynget tabel.
Der er også andre typer indekser leveret af SQL Server:
- Det unikke indeks gennemtvinger kolonneværdiernes unikke karakter;
- Det dækkende indeks indeholder alle kolonner, der anmodes om af forespørgslen;
- Det sammensatte indeks indeholder flere kolonner i indeksnøglen;
- Andre særlige indekstyper er XML-, Spatial- og Columnstore-indekser.
Fordelen ved SQL Server-indekset er, at det forbedrer forespørgslernes ydeevne. Det virker dog, hvis kun indekset er korrekt. Skulle du designe det forkert, vil det påvirke forespørgslernes ydeevne negativt og forbruge SQL Server-ressourcerne til at gemme og vedligeholde ubrugelige indekser.
At vælge det bedste indeks, der løser alle problemer, er ikke en let opgave. Tilføjelse af et nyt indeks kan fremskynde datahentningsprocessen, men det forsinker dataændringsprocesserne. Enhver ændring, der udføres i den underliggende tabel, reflekteres direkte til alle relaterede indekser for at holde dataene konsistente.
Det er derfor, du bør studere og teste det nye indekss effekt, før du opretter det i produktionsmiljøet. Det er også nødvendigt at overvåge dets påvirkning og brug efter implementering af det til produktionsmiljøet.
Faktorer, der skal overvejes, når man designer et nyt SQL Server-indeks
Den første faktor er databasearbejdsbelastningstypen . Antag, at vi har at gøre med en OLTP-arbejdsbelastning med et stort antal skriveoperationer. Det kræver det mindst mulige antal indekser. Et andet tilfælde er en OLAP-arbejdsbelastning med mange læseoperationer – det vil kræve så mange indekser som muligt for at fremskynde datahentningen.
Du skal også se på bordstørrelsen . SQL Server Engine foretrækker at scanne den underliggende tabel direkte i stedet for at spilde tid og ressourcer på at vælge det bedste indeks til datahentning fra den lille tabel.
Når du har besluttet at oprette et indeks på den tabel, skal du identificere indekstypen for at betjene din forespørgsel . Der angiver du de kolonner, der tilføjes til indeksnøglen. Baserne er kolonnens datatype og position i forespørgselsprædikaterne og joinbetingelser.
Disse faktorer bør garantere den bedste datahentningsydelse i den korrekte rækkefølge og holde indekset så kort og enkelt som muligt.
En anden faktor at overveje, når du designer et nyt indeks, er indekslageret . Det anbefales at oprette ikke-klyngede indekser på en separat filgruppe og diskdrev. På denne måde isolerer du de I/O-operationer, der udføres på indeksdatasiderne, fra databasedatafilerne.
Overvej at indstille indekset FYLDNINGSFAKTOR , som bestemmer procentdelen af plads på hver side på bladniveau fyldt med data (værdien afviger fra standardværdien 0 eller 100 procent). Målet er at efterlade plads på hver indeksdataside til de nyligt indsatte eller opdaterede poster. Det minimerer også forekomsten af sideopdelinger, der kan føre til indeksfragmenteringsproblemet.
Indeksstyring
Databaseadministratorens rolle i at forbedre forespørgslernes ydeevne med SQL Server-indekser er ikke begrænset til at oprette indekset. Du bør proaktivt overvåge indeksforbruget for at identificere dets kvalitet. Desuden er vi nødt til at vedligeholde indekset regelmæssigt for at løse fragmenteringsproblemerne.
SQL Server Management Studio giver med sin robuste rapporteringsfunktion de mest nyttige statistikdata til databaseadministratorerne. En af disse indbyggede rapporter er Indeksbrugsstatistik :
Rapporten Index Usage Statistics beskriver, hvordan databaseindekser bruges i form af:
- Søger :antallet af gange indekset bruges af SQL Engine til at finde en bestemt række.
- Scanninger :antallet af gange indeksbladssiderne scannes af SQL Engine.
- Opslag :antallet af gange, et ikke-klynget indeks blev brugt som et indekseret indeks for at hente resten af kolonnerne, der ikke er opført i det ikke-klyngede indeks.
- Opdateringer :antallet af gange, indeksdataene ændres.
Bemærk, at det primære formål med oprettelsen af indekset er at udføre en indekssøgning, som vist nedenfor:
Den tidligere rapport hjælper betydeligt med at specificere, om SQL Serveren udnytter disse indekser til at fremskynde datahentningsprocessen eller ej. Hvis det viser sig, at et bestemt indeks ikke fungerer, som det skal, skal du droppe det og erstatte det med et bedre.
Den anden rapport leveret af SSMS er Index Physical Statistics . Det returnerer de statistiske oplysninger om indeksfragmenteringsprocenten for hver indekspartition med antallet af sider på hver indekspartition.
Den anbefaler også, hvordan du løser problemer med indeksfragmentering ved at genopbygge eller omorganisere indekset i henhold til fragmenteringsprocenten som vist nedenfor:
For at anvende anbefalingerne fra rapporten kan du køre kommandoen indeksdefragmentering for hvert indeks. Eller du kan oprette en vedligeholdelsesplan ved hjælp af SSMS for at vedligeholde indekset på den bedste måde.
dbForge Index Manager
dbForge Index Manager er et SSMS-tilføjelsesprogram, der tjener til at detektere og løse problemer med fragmentering af SQL Server-indekser.
Det er også et centraliseret værktøj, der giver mulighed for at detektere indeksfragmenteringsprocenten på tværs af databaserne. Du kan løse disse problemer ved at udføre en indeksgenopbygning. En anden måde er at omorganisere operationer, baseret på fragmenteringsgraden af dette indeks. Blandt andre muligheder er der generering af T-SQL-scripts til udførelse af indeksrelaterede kommandoer, eksport af indeksanalyseresultater til senere reference og brug af kommandolinjegrænsefladen til at automatisere indeksvedligeholdelsesopgaverne.
dbForge Index Manager er tilgængelig på Devart-downloadsiden. Du kan installere det på din maskine ved hjælp af en simpel installationsguide. Efter en vellykket installation er dette tilføjelsesprogram klar til brug.
For at bruge det i SSMS'en skal du højreklikke på databasen og vælge Administrer indeksfragmentering fra listen Index Manager:
Fra Index Manager-vinduet kan du filtrere det databasenavn, der interesserer dig.
Klik på Genanalysere for at udføre indeksfragmenteringskontrollen for den valgte database. Den viser automatisk indeksfragmenteringsstatistikken for alle indekser, der er oprettet under den valgte database under denne proces.
Indeksstyringsværktøjet anbefaler også handlingerne til at løse problemerne med indeksfragmentering baseret på fragmenteringsprocenten:
Kontrol af indekser under sektionen Handlinger påkrævet i det forrige vindue gør det muligt at eksportere handlingslisten som en CSV-rapport. Det giver dig mulighed for at udføre den foreslåede rettelse ved at omorganisere eller genopbygge problematiske indekser direkte fra den side eller generere et script for at gøre det senere:
Indeksfragmenteringsrettelsen i vores scenarie vil være som nedenfor:
Hvis du kører det forrige script eller klikker på Ret mulighed, og derefter Genanalysere resultatet ser du, at fragmenteringsproblemet er løst direkte:
På denne måde udnytter vi dbForge Index Manager til at analysere og identificere problemer med indeksfragmentering og derefter rapportere eller rette dem direkte fra samme sted.
Nyttigt værktøj
dbForge Index Manager bringer smart indeksfiksering og indeksfragmentering direkte ind i SSMS. Værktøjet giver dig mulighed for hurtigt at indsamle indeksfragmenteringsstatistikker og opdage databaser, der kræver vedligeholdelse. Du kan øjeblikkeligt genopbygge og omorganisere SQL Server-indekser i visuel tilstand eller generere SQL-scripts til fremtidig brug. dbForge Index Manager til SQL Server vil øge din ydeevne markant uden stor indsats.