Index ( angol index ) – az adatvisszakeresés teljesítményének javítása érdekében létrehozott adatbázis -objektum . Az adatbázisban lévő táblák nagy számú sorral rendelkezhetnek, amelyek tetszőleges sorrendben vannak tárolva, és ezek adott kritérium szerinti keresése a tábla soronkénti szekvenciális átvizsgálásával sokáig tarthat. Az index a táblázat egy vagy több oszlopának értékéből és a táblázat megfelelő soraira mutató mutatókból áll, és így lehetővé teszi a keresési feltételeknek megfelelő sorok keresését. Az indexekkel végzett munka felgyorsítása elsősorban annak köszönhető, hogy az index keresésre optimalizált szerkezettel rendelkezik - például egy kiegyensúlyozott fa .
Egyes DBMS -ek kibővítik az indexek képességeit azáltal, hogy bevezetik indexek létrehozásának lehetőségét a nézetoszlopokon [1] vagy indexek létrehozását kifejezéseken. [2] Például egy indexet létrehozhat egy kifejezés upper(last_name), amely ennek megfelelően tárolja a hivatkozásokat, amelyek kulcsa a mező értéke last_namenagybetűs. Ezenkívül az indexeket egyediként vagy nem egyediként is deklarálhatjuk. Az egyedi index integritási megszorítást valósít meg a táblán, kiküszöbölve az ismétlődő értékek beszúrásának lehetőségét.
Kétféle index létezik: fürtözött és nem fürtözött. Ha van fürtözött index, a táblázat sorai az indexkulcs értéke szerint vannak rendezve. Ha a táblának nincs fürtözött indexe, a táblát kupacnak nevezzük [3] . Egy ilyen táblán létrehozott nem fürtözött index csak a tábla rekordjaira mutató mutatókat tartalmaz. Táblánként csak egy fürtözött index lehet, de minden táblának több különböző nem fürtözött indexe lehet, amelyek mindegyike saját rekordsorrendet határoz meg.
Az indexek különféle struktúrákkal valósíthatók meg. A leggyakrabban használt B*-fák , B+-fák , B-fák és hash -ek .
Nagyon fontos, hogy az oszlopok milyen sorrendben jelenjenek meg az összetett indexben. A lényeg az, hogy egy lekérdezéshez olyan adatkészletet lehet kapni, amely az indexelt oszlopok közül csak az elsőt érinti. A legtöbb DBMS-ben azonban lehetetlen vagy nem hatékony csak a második és további indexelt oszlopokra vonatkozó adatok lekérése (az első oszlopra nincs korlátozás)
Képzeljünk el például egy telefonkönyvet, amely először város, majd vezetéknév, majd keresztnév szerint van rendezve. Ha ismeri a várost, könnyen megtalálhatja a város összes telefonszámát. Egy ilyen könyvtárban azonban nagyon időigényes lesz megtalálni az összes vezetéknévhez rögzített telefont - ehhez meg kell keresnie az egyes városok szakaszát, és ott meg kell keresnie a kívánt vezetéknevet. Néhány DBMS elvégzi ezt a feladatot, mások egyszerűen nem használnak ilyen indexet.
Az optimális lekérdezési teljesítmény érdekében az indexek általában a lekérdezésekben gyakran használt táblázatoszlopokon jönnek létre. Ugyanazon a táblán több index is létrehozható. Az indexek számának növelése azonban lelassítja a táblázatsorok hozzáadásának, frissítésének, törlésének műveleteit, mivel magukat az indexeket kell frissíteni. Ezenkívül az indexek további memóriát foglalnak el, ezért az index létrehozása előtt győződjön meg arról, hogy a lekérdezések várható teljesítménynövekedése meghaladja a számítógépnek az index karbantartásához szükséges erőforrásainak többletköltségét.
Az indexek számos alkalmazáshoz hasznosak, de használatuknak vannak korlátozásai. Vegyük ezt az SQL lekérdezést :
SELECT first_name FROM people WHERE last_name = 'Frankenstein' ;Egy ilyen lekérdezés index nélküli végrehajtásához a DBMS-nek meg kell vizsgálnia egy mezőt last_namea tábla minden sorában (ez a mechanizmus „brute force” vagy „full table scan” néven ismert, és a tervben TERMÉSZETESként jeleníthető meg). Index használatakor a DBMS egyszerűen bejárja a B-fát, amíg meg nem találja a "Frankenstein" bejegyzést. Egy ilyen átadás sokkal kevesebb erőforrást igényel, mint a táblázat teljes keresése.
Most vegyük ezt a lekérdezést:
SELECT email_address FROM ügyfelek WHERE email_address LIKE '%@yahoo.com' ;Ennek a lekérdezésnek meg kell találnia minden olyan ügyfelet, akinek az e-mailje a végződéssel végződik @yahoo.com, de még ha email_addressvan is index az oszlopban, a DBMS továbbra is a tábla teljes keresését fogja használni. Ennek az az oka, hogy az indexek arra a feltételezésre épülnek, hogy a szavak/karakterek balról jobbra haladnak. A helyettesítő karakter használata a keresési feltétel elején megakadályozza, hogy a DBMS B-fa keresést használjon. Sok DBMS-ben ez a probléma megoldható egy további index létrehozásával kifejezéssel reverse(email_address)és egy lekérdezés létrehozásával, például:
SELECT email_address FROM ügyfelek WHERE fordított ( email_cím ) LIKE fordított ( '%@yahoo.com' );Ebben az esetben a helyettesítő karakter a jobb szélső pozícióban ( moc.oohay@%) jelenik meg, ami nem zárja ki az index használatát a -n reverse(email_address).
Általánosságban elmondható, hogy az adatbázisokban lévő index egy olyan fájl, amely kulcs- és mutatópárok sorozatát tartalmazza. [4] Az indexek használatának ötlete onnan eredt, hogy a modern adatbázisok túl masszívak ahhoz, hogy elférjenek a fő memóriában. Általában az adatokat blokkokra osztjuk, és a memóriában blokkonként osztjuk ki az adatokat. A rekord keresése az adatbázisban azonban sokáig tarthat. Másrészt egy indexfájl vagy indexblokk sokkal kisebb, mint egy adatblokk, és elfér egy fő memóriapufferben, ami felgyorsítja a rekordkeresést.
A ritka indexet az a tény jellemzi , hogy minden kulcs egy adott blokkmutatóhoz van társítva a rendezett adatfájlban.
A sűrű index viszont abban különbözik, hogy minden kulcs egy adott mutatóhoz van társítva egy rendezett adatfájlban lévő rekordhoz .
A duplikált kulcsokkal rendelkező fürtözött indexekben a ritka index az egyes blokkok legkisebb kulcsára mutat, míg a sűrű index a megadott kulccsal rendelkező első bejegyzésre mutat.
| Adatbázis | |
|---|---|
| Fogalmak |
|
| Objektumok |
|
| Kulcsok | |
| SQL |
|
| Alkatrészek | |