Index (databaser)

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 10 maj 2020; kontroller kräver 7 redigeringar .

Index ( engelsk  index ) - ett databasobjekt skapat för att förbättra prestandan för datahämtning . Tabeller i en databas kan ha ett stort antal rader som lagras i en godtycklig ordning, och att söka efter dem enligt ett givet kriterium genom att sekventiellt skanna tabellen rad för rad kan ta lång tid. Indexet bildas från värdena för en eller flera kolumner i tabellen och pekare till motsvarande rader i tabellen och låter dig därför söka efter rader som uppfyller sökkriterierna. Att påskynda arbetet med hjälp av index uppnås främst på grund av att indexet har en sökoptimerad struktur - till exempel ett balanserat träd .

Vissa DBMS utökar indexens möjligheter genom att införa möjligheten att skapa index vykolumner [1] eller index på uttryck. [2] Till exempel kan ett index skapas av ett uttryck upper(last_name)och kommer följaktligen att lagra referenser, vars nyckel kommer att vara fältets värde med last_nameversaler. Dessutom kan index deklareras som antingen unika eller icke-unika. Ett unikt index implementerar en integritetsbegränsning på en tabell, vilket eliminerar möjligheten att infoga dubbletter av värden.

Arkitektur

Det finns två typer av index: klustrade och icke-klustrade. Om det finns ett klustrat index, ordnas tabellraderna efter indexnyckelvärdet. Om en tabell inte har ett klustrat index kallas tabellen en heap [3] . Ett icke-klustrat index skapat på en sådan tabell innehåller endast pekare till tabellens poster. Det kan bara finnas ett klustrat index per tabell, men varje tabell kan ha flera olika icke-klustrade index, som vart och ett definierar sin egen postordning.

Index kan implementeras av olika strukturer. De vanligaste är B*-träd , B+-träd , B-träd och hash .

Sekvens av kolumner i ett sammansatt index

Ordningen i vilken kolumnerna visas i ett sammansatt index är ganska viktigt. Poängen är att det är möjligt att få en datamängd för en fråga som bara påverkar den första av de indexerade kolumnerna. Men i de flesta DBMS är det omöjligt eller ineffektivt att få data endast på den andra och ytterligare indexerade kolumner (inga begränsningar för den första kolumnen)

Tänk dig till exempel en telefonkatalog sorterad först efter stad, sedan efter efternamn och sedan efter förnamn. Om du känner till staden kan du enkelt hitta alla telefonnummer i den staden. Men i en sådan katalog kommer det att vara mycket tidskrävande att hitta alla telefoner som spelats in för ett visst efternamn - för detta måste du leta i avsnittet av varje stad och leta efter det önskade efternamnet där. Vissa DBMS gör det här jobbet, andra använder bara inte ett sådant index.

Prestanda

För optimal frågeprestanda skapas index vanligtvis på tabellkolumner som ofta används i frågor. Flera index kan skapas på samma tabell. Att öka antalet index saktar dock ner operationerna med att lägga till, uppdatera, ta bort tabellrader, eftersom själva indexen måste uppdateras. Dessutom tar index upp ytterligare minne, så innan du skapar ett index bör du se till att den förväntade prestandavinsten för frågor uppväger den extra kostnaden för din dators resurser för att underhålla indexet.

Begränsningar

Index är användbara för många applikationer, men det finns begränsningar för deras användning. Ta den här SQL -frågan :

SELECT first_name FROM people WHERE last_name = ' Frankenstein' ;

För att exekvera en sådan fråga utan ett index måste DBMS undersöka ett fält last_namei varje rad i tabellen (denna mekanism är känd som "brute force" eller "full table scan", och kan visas som NATURAL i planen). När du använder ett index, korsar DBMS helt enkelt B-trädet tills det hittar posten "Frankenstein". Ett sådant pass kräver mycket mindre resurser än en fullständig sökning i tabellen.

Låt oss nu ta denna fråga:

VÄLJ email_address FRÅN kunder VAR email_address SOM '%@yahoo.com' ;

Denna fråga bör hitta alla kunder vars e-post slutar med @yahoo.com, men även om email_addressdet finns ett index i kolumnen kommer DBMS fortfarande att använda en fullständig sökning i tabellen. Detta beror på att index bygger på antagandet att ord/tecken går från vänster till höger. Användningen av ett jokertecken i början av ett sökvillkor förhindrar DBMS från att använda en B-trädsökning. I många DBMS kan detta problem lösas genom att skapa ett extra index genom att uttrycka reverse(email_address)och skapa en fråga som:

SELECT email_address FRÅN kunder WHERE reverse ( email_address ) LIKE reverse ( '%@yahoo.com' );

I det här fallet kommer jokertecknet att visas längst till höger ( moc.oohay@%), vilket inte utesluter användningen av ett index på reverse(email_address).

Glest och tätt index

Generellt sett är ett index i databaser en fil med en sekvens av nycklar och pekare. [4] Idén att använda index kom från det faktum att moderna databaser är för stora för att passa i huvudminnet. Vi brukar dela in data i block och allokera data i minnet block för block. Att söka efter en post i databasen kan dock ta lång tid. Å andra sidan är en indexfil eller ett indexblock mycket mindre än ett datablock och kan passa i en huvudminnesbuffert, vilket påskyndar postsökningen.

Ett  sparsamt index kännetecknas av att varje nyckel är associerad med en specifik blockpekare i den sorterade datafilen.

Ett tätt index skiljer sig i sin tur genom att varje nyckel är associerad med en specifik pekare till en post i en sorterad datafil . 

I klustrade index med dubbletter av nycklar pekar det glesa indexet på den minsta nyckeln i varje block, medan det täta indexet pekar på den första posten med den angivna nyckeln.

Anteckningar

  1. Skapa indexerade vyer i MS SQL Server . Hämtad 10 augusti 2010. Arkiverad från originalet 3 december 2010.
  2. Använda ett index för uttryck i ORDER BY (PostgreSQL) . Hämtad 18 augusti 2011. Arkiverad från originalet 27 september 2011.
  3. Högstrukturer i MS SQL Server . Hämtad 10 augusti 2010. Arkiverad från originalet 24 mars 2011.
  4. Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer D. Widom. Databassystem: The Complete Book . - 2:a uppl. - Prentice Hall , 2008. - 1248 sid. — ISBN 978-0131873254 .