Index ( engelsk indeks ) - et databaseobjekt oprettet for at forbedre ydeevnen for datahentning . Tabeller i en database kan have et stort antal rækker, der er gemt i en vilkårlig rækkefølge, og at søge efter dem efter et givet kriterium ved sekventielt at scanne tabellen række for række kan tage lang tid. Indekset er dannet ud fra værdierne af en eller flere kolonner i tabellen og pointere til de tilsvarende rækker i tabellen og giver dig således mulighed for at søge efter rækker, der opfylder søgekriterierne. Fremskyndelse af arbejdet ved hjælp af indekser opnås primært på grund af, at indekset har en søgeoptimeret struktur - for eksempel et balanceret træ .
Nogle DBMS udvider mulighederne for indekser ved at introducere muligheden for at oprette indekser på visningskolonner [ 1] eller indekser på udtryk. [2] For eksempel kan et indeks oprettes af et udtryk upper(last_name)og vil følgelig gemme referencer, hvor nøglen vil være værdien af feltet last_namemed store bogstaver. Derudover kan indekser erklæres som enten unikke eller ikke-unikke. Et unikt indeks implementerer en integritetsbegrænsning på en tabel, hvilket eliminerer muligheden for at indsætte duplikerede værdier.
Der er to typer indekser: grupperede og ikke-klynger. Hvis der er et klynget indeks, er tabelrækkerne ordnet efter indeksnøgleværdien. Hvis en tabel ikke har et klynget indeks, kaldes tabellen en heap [3] . Et ikke-klynget indeks, der er oprettet på en sådan tabel, indeholder kun pointere til tabellens poster. Der kan kun være ét klynget indeks pr. tabel, men hver tabel kan have flere forskellige ikke-klyngede indekser, der hver definerer sin egen postrækkefølge.
Indekser kan implementeres af forskellige strukturer. De mest brugte er B*-træer , B+-træer , B-træer og hash .
Den rækkefølge, som kolonnerne vises i i et sammensat indeks, er ret vigtig. Pointen er, at det er muligt at få et datasæt til en forespørgsel, der kun påvirker den første af de indekserede kolonner. Men i de fleste DBMS er det umuligt eller ineffektivt kun at få data på den anden og yderligere indekserede kolonner (ingen begrænsninger på den første kolonne)
Forestil dig for eksempel en telefonbog, der først er sorteret efter by, derefter efter efternavn og derefter efter fornavn. Hvis du kender byen, kan du nemt finde alle telefonnumre i den by. Men i en sådan mappe vil det være meget tidskrævende at finde alle telefoner, der er optaget for et bestemt efternavn - for dette skal du kigge i sektionen af hver by og lede efter det ønskede efternavn der. Nogle DBMS udfører dette job, andre bruger bare ikke sådan et indeks.
For optimal forespørgselsydeevne oprettes indekser typisk på tabelkolonner, der ofte bruges i forespørgsler. Flere indekser kan oprettes på samme tabel. En forøgelse af antallet af indekser forsinker dog operationerne med at tilføje, opdatere, slette tabelrækker, da selve indeksene skal opdateres. Derudover optager indekser yderligere hukommelse, så før du opretter et indeks, bør du sikre dig, at den forventede ydeevnegevinst for forespørgsler vil opveje den ekstra overhead af din computers ressourcer til vedligeholdelse af indekset.
Indekser er nyttige til mange applikationer, men der er begrænsninger for deres brug. Tag denne SQL- forespørgsel :
SELECT first_name FROM people WHERE last_name = 'Frankenstein' ;For at udføre en sådan forespørgsel uden et indeks skal DBMS undersøge et felt last_namei hver række i tabellen (denne mekanisme er kendt som "brute force" eller "fuld tabelscanning", og kan vises som NATURAL i planen). Når du bruger et indeks, krydser DBMS blot B-træet, indtil det finder indgangen "Frankenstein". Sådan et pas kræver meget færre ressourcer end en komplet søgning i tabellen.
Lad os nu tage denne forespørgsel:
VÆLG email_address FRA kunder HVOR email_address LIKE '%@yahoo.com' ;Denne forespørgsel skal finde alle kunder, hvis e-mail ender med @yahoo.com, men selvom email_addressder er et indeks på kolonnen, vil DBMS stadig bruge en komplet søgning i tabellen. Dette skyldes, at indekser er bygget ud fra den antagelse, at ord/tegn går fra venstre mod højre. Brugen af et jokertegn i begyndelsen af en søgebetingelse forhindrer DBMS i at bruge en B-træsøgning. I mange DBMS kan dette problem løses ved at oprette et ekstra indeks ved at udtrykke reverse(email_address)og danne en forespørgsel som:
VÆLG email_address FRA kunder WHERE reverse ( email_address ) LIKE reverse ( '%@yahoo.com' );I dette tilfælde vil jokertegnet vises i positionen længst til højre ( moc.oohay@%), hvilket ikke udelukker brugen af et indeks på reverse(email_address).
Generelt er et indeks i databaser en fil med en sekvens af par af nøgler og pointere. [4] Ideen om at bruge indekser kom fra det faktum, at moderne databaser er for massive til at passe ind i hovedhukommelsen. Vi opdeler normalt data i blokke og allokerer data i hukommelsen blok for blok. Det kan dog tage lang tid at søge efter en post i databasen. På den anden side er en indeksfil eller indeksblok meget mindre end en datablok og kan passe ind i en hovedhukommelsesbuffer, hvilket fremskynder postopslag.
Et sparsomt indeks er kendetegnet ved, at hver nøgle er knyttet til en specifik blokpointer i den sorterede datafil.
Et tæt indeks adskiller sig til gengæld ved, at hver nøgle er knyttet til en specifik pointer til en post i en sorteret datafil .
I klyngede indekser med duplikerede nøgler peger det sparsomme indeks på den mindste nøgle i hver blok, mens det tætte indeks peger på den første indgang med den angivne nøgle.
| Database | |
|---|---|
| Begreber |
|
| Objekter | |
| Nøgler | |
| SQL | |
| Komponenter | |