Eden najpomembnejših načinov za doseganje visokozmogljivo SQL Server je uporaba indeksov. Indeks pospeši postopek poizvedbe z zagotavljanjem hiter dostop na vrstice podatkov v tabeli, podobno kot kazalo v knjigi, vam pomaga hitro najti informacije, ki jih potrebujete. V tem članku bom dal kratek pregled indeksi v SQL Server in pojasnite, kako so organizirani v bazi podatkov in kako pomagajo pospešiti poizvedbe po bazi podatkov.

Indeksi so ustvarjeni v stolpcih tabele in pogleda. Indeksi omogočajo hitro iskanje podatkov na podlagi vrednosti v teh stolpcih. Na primer, če ustvarite indeks na primarnem ključu in nato iščete vrstico podatkov z uporabo vrednosti primarnega ključa, potem SQL Server bo najprej našel vrednost indeksa in nato uporabil indeks za hitro iskanje celotne vrstice podatkov. Brez indeksa bo izveden popoln pregled vseh vrstic v tabeli, kar lahko pomembno vpliva na zmogljivost.
Ustvarite lahko indeks za večino stolpcev v tabeli ali pogledu. Izjema so predvsem stolpci s podatkovnimi tipi za shranjevanje velikih objektov ( LOB), kot naprimer slika, besedilo oz varchar(max). Prav tako lahko ustvarite indekse na stolpcih, namenjenih shranjevanju podatkov v formatu XML, vendar so ti indeksi strukturirani nekoliko drugače kot standardni in njihovo obravnavanje presega obseg tega članka. Poleg tega članek ne razpravlja columnstore indeksi. Namesto tega se osredotočam na tiste indekse, ki se najpogosteje uporabljajo v zbirkah podatkov SQL Server.
Indeks je sestavljen iz niza strani, indeksnih vozlišč, ki so organizirana v drevesni strukturi – uravnoteženo drevo. Ta struktura je hierarhične narave in se začne s korenskim vozliščem na vrhu hierarhije in listnimi vozlišči, listi, na dnu, kot je prikazano na sliki:


Ko poizvedujete po indeksiranem stolpcu, se poizvedovalni mehanizem začne na vrhu korenskega vozlišča in se prebija navzdol skozi vmesna vozlišča, pri čemer vsaka vmesna plast vsebuje podrobnejše informacije o podatkih. Mehanizem poizvedb se še naprej premika skozi vozlišča indeksa, dokler ne doseže spodnje ravni z listi indeksa. Če na primer iščete vrednost 123 v indeksiranem stolpcu, bo mehanizem poizvedb najprej določil stran na prvi vmesni ravni na korenski ravni. V tem primeru prva stran kaže na vrednost od 1 do 100, druga pa od 101 do 200, zato bo poizvedovalnik dostopal do druge strani te vmesne ravni. Nato boste videli, da bi morali obrniti na tretjo stran naslednje vmesne stopnje. Od tu bo poizvedovalni podsistem prebral vrednost samega indeksa na nižji ravni. Listi indeksa lahko vsebujejo same podatke tabele ali preprosto kazalec na vrstice s podatki v tabeli, odvisno od vrste indeksa: gručasti indeks ali negručasti indeks.

Clustered Index

Gručni indeks shranjuje dejanske vrstice podatkov v listih indeksa. Če se vrnemo k prejšnjemu primeru, to pomeni, da bo vrstica podatkov, povezana z vrednostjo ključa 123, shranjena v samem indeksu. Pomembna lastnost Gručasti indeks pomeni, da so vse vrednosti razvrščene v določenem vrstnem redu, bodisi naraščajoče bodisi padajoče. Zato ima lahko tabela ali pogled samo en gručasti indeks. Poleg tega je treba upoštevati, da so podatki v tabeli shranjeni v razvrščeni obliki le, če je bil v tej tabeli ustvarjen gručasti indeks.
Tabela, ki nima gručastega indeksa, se imenuje kopica.

Indeks brez gruč

Za razliko od gručastega indeksa listi negručastega indeksa vsebujejo samo tiste stolpce ( ključ), s katerim se določi ta indeks, vsebuje pa tudi kazalec na vrstice z realnimi podatki v tabeli. To pomeni, da sistem podpoizvedb zahteva dodatno operacijo za iskanje in pridobivanje zahtevanih podatkov. Vsebina podatkovnega kazalca je odvisna od tega, kako so podatki shranjeni: gručasta tabela ali kopica. Če kazalec kaže na gručasto tabelo, kaže na gručasti indeks, ki ga je mogoče uporabiti za iskanje dejanskih podatkov. Če se kazalec nanaša na kopico, potem kaže na določen identifikator podatkovne vrstice. Indeksov brez gruč ni mogoče razvrstiti kot indeksov v gručah, lahko pa ustvarite več kot en indeks brez gruč v tabeli ali pogledu, do 999. To ne pomeni, da bi morali ustvariti čim več indeksov. Indeksi lahko izboljšajo ali poslabšajo delovanje sistema. Poleg tega, da lahko ustvarite več negručastih indeksov, lahko vključite tudi dodatne stolpce ( vključen stolpec) v svoj indeks: listi indeksa ne bodo shranili le vrednosti samih indeksiranih stolpcev, ampak tudi vrednosti teh neindeksiranih dodatnih stolpcev. Ta pristop vam bo omogočil, da zaobidete nekatere omejitve, ki veljajo za indeks. Vključite lahko na primer stolpec, ki ga ni mogoče indeksirati, ali obidete omejitev dolžine indeksa (v večini primerov 900 bajtov).

Vrste indeksov

Poleg tega, da je indeks gručast ali ne, ga je mogoče nadalje konfigurirati kot sestavljeni indeks, edinstven indeks ali pokrivni indeks.

Sestavljeni indeks

Takšen indeks lahko vsebuje več kot en stolpec. V indeks lahko vključite do 16 stolpcev, vendar je njihova skupna dolžina omejena na 900 bajtov. Tako gručasti kot negručasti indeksi so lahko sestavljeni.

Edinstveni indeks

Ta indeks zagotavlja, da je vsaka vrednost v indeksiranem stolpcu edinstvena. Če je indeks sestavljen, velja edinstvenost za vse stolpce v indeksu, ne pa za vsak posamezen stolpec. Na primer, če ustvarite edinstven indeks za stolpce IME in PRIIMEK, To polno ime mora biti unikaten, vendar so možni dvojniki v imenu ali priimku.
Edinstveni indeks se samodejno ustvari, ko definirate omejitev stolpca: primarni ključ ali omejitev edinstvene vrednosti:

• Primarni ključ
  Ko določite omejitev primarnega ključa za enega ali več stolpcev, potem SQL Server samodejno ustvari unikaten gručasti indeks, če gručasti indeks še ni bil ustvarjen (v tem primeru se na primarnem ključu ustvari unikaten negručni indeks)
• Edinstvenost vrednot
  Ko določite omejitev za edinstvenost vrednosti, potem SQL Server samodejno ustvari edinstven negručast indeks. Določite lahko, da se ustvari enolični gručasti indeks, če v tabeli še ni bil ustvarjen noben gručni indeks

Pokrivni indeks

Takšen indeks omogoča, da posebna poizvedba takoj pridobi vse potrebne podatke iz listov indeksa brez dodatnega dostopa do zapisov same tabele.

Oblikovanje indeksov

Indeksi so še tako uporabni, vendar jih je treba skrbno oblikovati. Ker lahko indeksi zavzamejo veliko prostora na disku, ne želite ustvariti več indeksov, kot je potrebno. Poleg tega se indeksi samodejno posodobijo, ko se posodobi sama podatkovna vrstica, kar lahko privede do dodatnih stroškov virov in poslabšanja zmogljivosti. Pri oblikovanju indeksov je treba upoštevati več vidikov v zvezi z bazo podatkov in poizvedbami po njej.

Baza podatkov

Kot smo že omenili, lahko indeksi izboljšajo delovanje sistema, ker poizvedovalniku zagotavljajo hiter način iskanja podatkov. Vendar morate upoštevati tudi, kako pogosto nameravate vnašati, posodabljati ali brisati podatke. Ko spremenite podatke, je treba spremeniti tudi indekse, da odražajo ustrezna dejanja na podatkih, kar lahko znatno zmanjša zmogljivost sistema. Pri načrtovanju strategije indeksiranja upoštevajte naslednje smernice:

• Za tabele, ki se pogosto posodabljajo, uporabite čim manj indeksov.
• Če tabela vsebuje veliko količino podatkov, vendar so spremembe manjše, potem uporabite toliko indeksov, kot je potrebno, da izboljšate učinkovitost svojih poizvedb. Vendar dobro premislite, preden uporabite indekse na majhnih tabelah, ker ... Možno je, da iskanje po indeksu traja dlje kot preprosto pregledovanje vseh vrstic.
• Pri gručastih indeksih poskusite ohraniti polja čim krajša. Najboljši pristop je uporaba gručastega indeksa za stolpce, ki imajo edinstvene vrednosti in ne dovoljujejo NULL. Zato se primarni ključ pogosto uporablja kot gručni indeks.
• Edinstvenost vrednosti v stolpcu vpliva na uspešnost indeksa. Na splošno velja, da več kot imate dvojnikov v stolpcu, slabše deluje indeks. Po drugi strani pa več kot je edinstvenih vrednosti, boljša je uspešnost indeksa. Kadar koli je to mogoče, uporabite edinstven indeks.
• Pri sestavljenem indeksu upoštevajte vrstni red stolpcev v indeksu. Stolpci, ki se uporabljajo v izrazih KJE(Na primer, WHERE FirstName = "Charlie") mora biti prvi v indeksu. Naslednje stolpce je treba navesti glede na edinstvenost njihovih vrednosti (na prvem mestu so stolpci z največjim številom edinstvenih vrednosti).
• Podate lahko tudi indeks za izračunane stolpce, če izpolnjujejo določene zahteve. Na primer, izrazi, uporabljeni za pridobitev vrednosti stolpca, morajo biti deterministični (vedno vrnejo isti rezultat za dani niz vhodnih parametrov).

Poizvedbe po bazi podatkov

Pri oblikovanju indeksov je treba upoštevati še to, katere poizvedbe se izvajajo v bazi podatkov. Kot smo že omenili, morate upoštevati, kako pogosto se podatki spreminjajo. Poleg tega je treba uporabiti naslednja načela:

• Poskusite vstaviti ali spremeniti čim več vrstic v eni poizvedbi, namesto da to storite v več posameznih poizvedbah.
• Ustvarite negručasti indeks za stolpce, ki se pogosto uporabljajo kot iskalni izrazi v vaših poizvedbah. KJE in povezave v PRIDRUŽI SE.
• Razmislite o indeksiranju stolpcev, ki se uporabljajo v poizvedbah za iskanje vrstic za natančna ujemanja vrednosti.

In zdaj pravzaprav:

14 vprašanj o indeksih v strežniku SQL, ki vam jih je bilo sram vprašati

Zakaj tabela ne more imeti dveh gručastih indeksov?

Želite kratek odgovor? Gručni indeks je tabela. Ko v tabeli ustvarite gručasti indeks, mehanizem za shranjevanje razvrsti vse vrstice v tabeli v naraščajočem ali padajočem vrstnem redu glede na definicijo indeksa. Gručni indeks ni ločena entiteta kot drugi indeksi, temveč mehanizem za razvrščanje podatkov v tabeli in omogočanje hitrega dostopa do podatkovnih vrstic.
Predstavljajmo si, da imate tabelo, ki vsebuje zgodovino prodajnih transakcij. Tabela Prodaja vključuje informacije, kot so ID naročila, položaj izdelka v naročilu, številka izdelka, količina izdelka, številka in datum naročila itd. Ustvarite gručasti indeks na stolpcih Številka naročila in LineID, razvrščenih v naraščajočem vrstnem redu, kot je prikazano spodaj T-SQL Koda:
USTVARI UNIQUE CLUSTERED INDEX ix_oriderid_lineid ON dbo.Sales(OrderID, LineID);
Ko zaženete ta skript, bodo vse vrstice v tabeli fizično razvrščene najprej po stolpcu OrderID in nato po LineID, vendar bodo sami podatki ostali v enem samem logičnem bloku, tabeli. Iz tega razloga ne morete ustvariti dveh indeksov v gručah. Obstaja lahko samo ena tabela z enimi podatki in ta tabela je lahko razvrščena samo enkrat v določenem vrstnem redu.

Če gručasta tabela nudi številne prednosti, zakaj potem uporabljati kopico?

Prav imaš. Gručaste tabele so odlične in večina vaših poizvedb bo bolje delovala na tabelah, ki imajo gručast indeks. Toda v nekaterih primerih boste morda želeli pustiti mize v njihovem naravnem, neokrnjenem stanju, tj. v obliki kopice in ustvarite samo negručne indekse, da se vaše poizvedbe izvajajo.
Kopica, kot se spomnite, shranjuje podatke v naključnem vrstnem redu. Običajno podsistem za shranjevanje dodaja podatke v tabelo v vrstnem redu, v katerem so vstavljeni, vendar podsistem za shranjevanje rad tudi premika vrstice za učinkovitejše shranjevanje. Posledično ne morete predvideti, v kakšnem vrstnem redu bodo podatki shranjeni.
Če mora poizvedovalni mehanizem najti podatke brez prednosti negručenega indeksa, bo izvedel popoln pregled tabele, da bi našel vrstice, ki jih potrebuje. Na zelo majhnih mizah to običajno ni problem, a ko se kopica poveča, zmogljivost hitro pade. Seveda lahko negručasti indeks pomaga z uporabo kazalca na datoteko, stran in vrstico, kjer so shranjeni potrebni podatki - običajno je to veliko več najboljša alternativa skeniranje mize. Kljub temu je težko primerjati prednosti gručastega indeksa, če upoštevamo zmogljivost poizvedbe.
Vendar lahko kup pomaga izboljšati zmogljivost v določenih situacijah. Razmislite o tabeli z velik znesek vstavitve, vendar z redkimi posodobitvami ali brisanjem podatkov. Na primer, tabela, ki shranjuje dnevnik, se uporablja predvsem za vstavljanje vrednosti, dokler ni arhivirana. Na kopici ne boste videli stranjenja in fragmentacije podatkov, kot bi to storili z indeksom v gručah, ker so vrstice preprosto dodane na konec kopice. Preveč razdeljenih strani lahko pomembno vpliva na učinkovitost, a ne v dobrem smislu. Na splošno vam kopica omogoča razmeroma neboleče vstavljanje podatkov in ne bo vam treba ukvarjati s stroški shranjevanja in vzdrževanja, kot bi se morali ukvarjati z gručnim indeksom.
Vendar pomanjkanje posodabljanja in brisanja podatkov ne sme biti edini razlog. Pomemben dejavnik je tudi način vzorčenja podatkov. Na primer, kopice ne smete uporabljati, če pogosto poizvedujete po obsegih podatkov ali če je treba podatke, po katerih poizvedujete, pogosto razvrstiti ali združiti.
Vse to pomeni, da morate o uporabi kopice razmisliti le, ko delate z zelo majhnimi tabelami ali če je vsa vaša interakcija s tabelo omejena na vstavljanje podatkov in so vaše poizvedbe izjemno preproste (in uporabljate negručne indekse vseeno). V nasprotnem primeru se držite dobro zasnovanega gručastega indeksa, kot je tisti, ki je definiran na preprostem naraščajočem ključnem polju, kot je pogosto uporabljen stolpec z IDENTITETA.

Kako spremenim privzeti faktor polnjenja indeksa?

Spreminjanje privzetega faktorja polnjenja indeksa je ena stvar. Razumevanje delovanja privzetega razmerja je druga stvar. Toda najprej naredite nekaj korakov nazaj. Faktor polnjenja indeksa določa količino prostora na strani za shranjevanje indeksa na spodnji ravni (raven listov) pred začetkom polnjenja nova stran. Na primer, če je koeficient nastavljen na 90, potem ko indeks raste, bo zasedel 90% strani in se nato premaknil na naslednjo stran.
Privzeto je vključena vrednost faktorja polnjenja indeksa SQL Server je 0, kar je enako kot 100. Posledično vsi novi indeksi samodejno podedujejo to nastavitev, razen če v kodi izrecno podate vrednost, ki se razlikuje od sistemske standardne vrednosti, ali spremenite privzeto vedenje. Lahko uporabiš SQL Server Management Studio da prilagodite privzeto vrednost ali zaženete sistemsko shranjeno proceduro sp_configure. Na primer, naslednji niz T-SQL ukazi nastavi vrednost koeficienta na 90 (najprej morate preklopiti v način naprednih nastavitev):
EXEC sp_configure "pokaži napredne možnosti", 1; POJDI NA ZNOVA KONFIGURIRANJE; GO EXEC sp_configure "faktor polnjenja", 90; POJDI NA ZNOVA KONFIGURIRANJE; POJDI
Po spremembi vrednosti faktorja polnjenja indeksa morate znova zagnati storitev SQL Server. Zdaj lahko preverite nastavljeno vrednost tako, da zaženete sp_configure brez podanega drugega argumenta:
EXEC sp_configure "faktor polnjenja" GO
Ta ukaz bi moral vrniti vrednost 90. Posledično bodo vsi na novo ustvarjeni indeksi uporabljali to vrednost. To lahko preizkusite tako, da ustvarite indeks in poizvedujete za vrednost faktorja polnjenja:
UPORABA AdventureWorks2012; -- vaša zbirka podatkov GO CREATE NONCLUSTERED INDEX ix_people_lastname ON Person.Person(LastName); POJDI IZBERI fill_factor FROM sys.indexes WHERE object_id = object_id("Person.Person") AND name="ix_people_lastname";
IN v tem primeru na tabeli smo ustvarili negručast indeks Oseba v bazi podatkov AdventureWorks2012. Po izdelavi indeksa lahko pridobimo vrednost faktorja polnjenja iz sistemskih tabel sys.indexes. Poizvedba bi morala vrniti 90.
Predstavljajmo si, da smo izbrisali indeks in ga znova ustvarili, zdaj pa smo določili določeno vrednost faktorja polnjenja:
CREATE NONCLUSTERED INDEX ix_people_lastname ON Person.Person(LastName) WITH (fillfactor=80); POJDI IZBERI fill_factor FROM sys.indexes WHERE object_id = object_id("Person.Person") AND name="ix_people_lastname";
Tokrat smo dodali navodila Z in možnost faktor polnjenja za našo operacijo ustvarjanja indeksa USTVARI INDEKS in podali vrednost 80. Operator IZBERI zdaj vrne ustrezno vrednost.
Doslej je bilo vse precej preprosto. V celotnem procesu se lahko resnično opečete, ko ustvarite indeks, ki uporablja privzeto vrednost koeficienta, ob predpostavki, da to vrednost poznate. Na primer, nekdo se poigrava z nastavitvami strežnika in je tako trmast, da je faktor polnjenja indeksa nastavil na 20. Medtem pa vi nadaljujete z ustvarjanjem indeksov, ob predpostavki, da je privzeta vrednost 0. Na žalost ne morete ugotoviti polnila faktor, dokler ne ustvarite indeksa in nato preverite vrednost, kot smo storili v naših primerih. V nasprotnem primeru boste morali počakati na trenutek, ko se zmogljivost poizvedb toliko zmanjša, da začnete nekaj sumiti.
Druga težava, ki se je morate zavedati, je vnovična izgradnja indeksov. Tako kot pri izdelavi indeksa lahko podate vrednost faktorja polnjenja indeksa, ko ga znova sestavite. Za razliko od ukaza create index pa rebuild ne uporablja privzetih nastavitev strežnika, ne glede na to, kako se morda zdi. Še več, če izrecno ne določite vrednosti faktorja polnjenja indeksa SQL Server bo uporabil vrednost koeficienta, s katerim je ta indeks obstajal pred njegovim prestrukturiranjem. Na primer naslednja operacija SPREMENI INDEKS ponovno zgradi indeks, ki smo ga pravkar ustvarili:
ALTER INDEX ix_people_lastname ON Person.Person REBUILD; POJDI IZBERI fill_factor FROM sys.indexes WHERE object_id = object_id("Person.Person") AND name="ix_people_lastname";
Ko preverimo vrednost faktorja polnjenja, bomo dobili vrednost 80, ker smo to določili, ko smo nazadnje ustvarili indeks. Privzeta vrednost je prezrta.
Kot lahko vidite, spreminjanje vrednosti faktorja polnjenja indeksa ni tako težko. Veliko težje je poznati trenutno vrednost in razumeti, kdaj je uporabljena. Če vedno posebej določite koeficient pri ustvarjanju in ponovni gradnji indeksov, potem vedno poznate konkreten rezultat. Razen če vas mora skrbeti, da nekdo drug spet ne pokvari nastavitev strežnika, zaradi česar bodo vsi indeksi ponovno izdelani s smešno nizkim faktorjem polnjenja indeksa.

Ali je mogoče ustvariti gručasti indeks v stolpcu, ki vsebuje dvojnike?

Da in ne. Da, ustvarite lahko gručasti indeks na ključnem stolpcu, ki vsebuje podvojene vrednosti. Ne, vrednost ključnega stolpca ne more ostati v needinstvenem stanju. Naj pojasnim. Če v stolpcu ustvarite needinstven gručasti indeks, mehanizem za shranjevanje podvojeni vrednosti doda poenotelnik, da zagotovi edinstvenost in tako lahko identificira vsako vrstico v gručasti tabeli.
Na primer, lahko se odločite ustvariti gručasti indeks v stolpcu, ki vsebuje podatke o strankah Priimek ohranitev priimka. Stolpec vsebuje vrednosti Franklin, Hancock, Washington in Smith. Nato znova vstavite vrednosti Adams, Hancock, Smith in Smith. Toda vrednost stolpca ključa mora biti edinstvena, zato bo mehanizem za shranjevanje spremenil vrednost dvojnikov, tako da bodo videti nekako takole: Adams, Franklin, Hancock, Hancock1234, Washington, Smith, Smith4567 in Smith5678.
Na prvi pogled se ta pristop zdi v redu, vendar celoštevilska vrednost poveča velikost ključa, kar lahko postane težava, če obstaja veliko število dvojnikov, te vrednosti pa bodo postale osnova negručenega indeksa ali tujega ključna referenca. Zaradi teh razlogov morate vedno poskušati ustvariti edinstvene indekse v gručah, kadar koli je to mogoče. Če to ni mogoče, potem vsaj poskusite uporabiti stolpce z zelo visoko vsebnostjo edinstvenih vrednosti.

Kako je tabela shranjena, če ni bil ustvarjen gručasti indeks?

SQL Server podpira dve vrsti tabel: gručaste tabele, ki imajo gručast indeks, in kopične tabele ali samo kopice. Za razliko od gručastih tabel podatki na kupu niso razvrščeni na noben način. V bistvu je to kup (kup) podatkov. Če v takšno tabelo dodate vrstico, jo bo mehanizem za shranjevanje preprosto dodal na konec strani. Ko bo stran napolnjena s podatki, bodo dodani na novo stran. V večini primerov boste želeli ustvariti gručasti indeks v tabeli, da boste izkoristili zmožnosti razvrščanja in hitrejše poizvedbe (poskusite si predstavljati iskanje telefonska številka v imeniku, ki ni razvrščen po nobenem principu). Če pa se odločite, da ne boste ustvarili gručastega indeksa, lahko še vedno ustvarite negručasti indeks na kopici. V tem primeru bo imela vsaka indeksna vrstica kazalec na vrstico kopice. Kazalo vključuje ID datoteke, številko strani in številko podatkovne vrstice.

Kakšno je razmerje med omejitvami edinstvenosti vrednosti in primarnim ključem z indeksi tabele?

Primarni ključ in edinstvena omejitev zagotavljata, da so vrednosti v stolpcu edinstvene. Za tabelo lahko ustvarite samo en primarni ključ, ki ne more vsebovati vrednosti NIČ. Ustvarite lahko več omejitev glede edinstvenosti vrednosti za tabelo in vsaka od njih ima lahko en zapis z NIČ.
Ko ustvarite primarni ključ, mehanizem za shranjevanje ustvari tudi edinstven indeks v gručah, če indeks v gručah še ni bil ustvarjen. Vendar pa lahko preglasite privzeto vedenje in ustvarjen bo negručast indeks. Če ob ustvarjanju primarnega ključa obstaja indeks v gručah, bo ustvarjen enolični indeks brez gruč.
Ko ustvarite edinstveno omejitev, mehanizem za shranjevanje ustvari edinstven, negručen indeks. Vendar pa lahko določite ustvarjanje edinstvenega indeksa v gručah, če še niste bili ustvarjeni.
Na splošno sta omejitev edinstvene vrednosti in edinstveni indeks ista stvar.

Zakaj se gručasti in negručasti indeksi v SQL Serverju imenujejo B-drevo?

Osnovni indeksi v SQL Serverju, v gručah ali brez njih, so porazdeljeni po naborih strani, imenovanih indeksna vozlišča. Te strani so organizirane v določeni hierarhiji z drevesno strukturo, imenovano uravnoteženo drevo. Na zgornji ravni je korensko vozlišče, na dnu so listna vozlišča z vmesnimi vozlišči med zgornjim in spodnjim nivojem, kot je prikazano na sliki:


Korensko vozlišče zagotavlja glavno vstopno točko za poizvedbe, ki poskušajo pridobiti podatke prek indeksa. Začenši s tem vozliščem, poizvedovalni podsistem sproži prehod hierarhično strukturo navzdol do ustreznega listnega vozlišča, ki vsebuje podatke.
Na primer, predstavljajte si, da je bila prejeta zahteva za izbiro vrstic, ki vsebujejo vrednost ključa 82. Poizvedbeni podsistem začne delovati iz korenskega vozlišča, ki se nanaša na ustrezno vmesno vozlišče, v našem primeru 1-100. Iz vmesnega vozlišča 1-100 poteka prehod v vozlišče 51-100, od tam pa v končno vozlišče 76-100. Če je to indeks v gručah, potem list vozlišča vsebuje podatke vrstice, povezane s ključem, ki je enak 82. Če je to indeks brez gruč, potem list indeksa vsebuje kazalec na tabelo v gručah ali določeno vrstico v kup.

Kako lahko indeks sploh izboljša zmogljivost poizvedbe, če morate prečkati vsa ta vozlišča indeksa?

Prvič, indeksi ne izboljšajo vedno učinkovitosti. Preveč nepravilno ustvarjenih indeksov spremeni sistem v močvirje in poslabša zmogljivost poizvedb. Natančneje je reči, da lahko indeksi, če so skrbno uporabljeni, zagotovijo znatno povečanje učinkovitosti.
Pomislite na ogromno knjigo, posvečeno uglaševanju zmogljivosti SQL Server(papirnata, ne elektronska). Predstavljajte si, da želite najti informacije o konfiguriranju regulatorja virov. S prstom lahko vlečete stran za stranjo skozi celotno knjigo ali pa odprete kazalo in ugotovite točno številko strani z iskanimi informacijami (pod pogojem, da je knjiga pravilno indeksirana in ima vsebina pravilna kazala). To vam bo zagotovo prihranilo precej časa, čeprav morate najprej dostopati do popolnoma drugačne strukture (indeksa), da dobite informacije, ki jih potrebujete iz primarne strukture (knjige).
Kot knjižno kazalo, kazalo v SQL Server omogoča izvajanje natančnih poizvedb po podatkih, ki jih potrebujete, namesto popolnega skeniranja vseh podatkov v tabeli. Pri majhnih tabelah popoln pregled običajno ni težava, vendar velike tabele zavzamejo veliko strani podatkov, kar lahko povzroči precejšen čas izvajanja poizvedbe, razen če obstaja indeks, ki omogoča mehanizmu poizvedb, da takoj pridobi pravilno lokacijo podatkov. Predstavljajte si, da se izgubite na večnivojskem križišču pred veliko metropolo brez zemljevida in dobili boste idejo.

Če so indeksi tako odlični, zakaj ne bi preprosto ustvarili enega za vsak stolpec?

Nobeno dobro dejanje ne sme ostati nekaznovano. Vsaj pri indeksih je tako. Seveda indeksi delujejo odlično, dokler izvajate poizvedbe za pridobivanje operaterja IZBERI, a takoj, ko se začnejo pogosti klici operaterjem VSTAVI, NADGRADNJA in IZBRIŠI, zato se pokrajina zelo hitro spreminja.
Ko sprožite zahtevo po podatkih s strani operaterja IZBERI, poizvedovalni mehanizem najde indeks, se premika po njegovi drevesni strukturi in odkrije podatke, ki jih išče. Kaj bi lahko bilo bolj preprosto? Toda stvari se spremenijo, če sprožite izjavo o spremembi, kot je NADGRADNJA. Da, za prvi del izjave lahko poizvedovalni mehanizem spet uporabi indeks za iskanje vrstice, ki se spreminja - to je dobra novica. In če pride do preproste spremembe podatkov v vrstici, ki ne vpliva na spremembe v ključnih stolpcih, bo postopek spreminjanja popolnoma neboleč. Toda kaj, če sprememba povzroči razdelitev strani, ki vsebujejo podatke, ali se spremeni vrednost ključnega stolpca, zaradi česar se premakne v drugo vozlišče indeksa – zaradi tega bo indeks verjetno potreboval reorganizacijo, ki bo vplivala na vse povezane indekse in operacije , kar ima za posledico obsežno zmanjšanje produktivnosti.
Podobni procesi se zgodijo pri klicu operaterja IZBRIŠI. Indeks lahko pomaga najti podatke, ki se brišejo, vendar lahko brisanje samih podatkov povzroči prerazporeditev strani. Glede operaterja VSTAVI, glavni sovražnik vseh indeksov: začnete dodajati veliko količino podatkov, kar povzroči spremembe v indeksih in njihovo reorganizacijo, pri čemer trpijo vsi.
Zato upoštevajte vrste poizvedb v vaši bazi podatkov, ko razmišljate o vrsti indeksov in koliko ustvariti. Več ne pomeni boljše. Pred dodajanjem novega indeksa v tabelo upoštevajte stroške ne samo osnovnih poizvedb, ampak tudi količino porabljenega prostora na disku, stroške vzdrževanja funkcionalnosti in indeksov, kar lahko povzroči domino učinek na druge operacije. Vaša strategija oblikovanja indeksa je eden najpomembnejših vidikov vaše implementacije in mora vključevati veliko premislekov, od velikosti indeksa, števila edinstvenih vrednosti do vrste poizvedb, ki jih bo indeks podpiral.

Ali je treba ustvariti gručasti indeks v stolpcu s primarnim ključem?

Indeks v gručah lahko ustvarite v katerem koli stolpcu, ki izpolnjuje zahtevane pogoje. Res je, da sta gručasti indeks in omejitev primarnega ključa ustvarjena drug za drugega in se ujemata v nebesih, zato razumejte dejstvo, da ko ustvarite primarni ključ, bo samodejno ustvarjen gručni indeks, če še ni bil ustvarjen prej. Lahko pa se odločite, da bi indeks v gručah deloval bolje drugje, in pogosto bo vaša odločitev upravičena.
Glavni namen gručastega indeksa je razvrstiti vse vrstice v vaši tabeli glede na ključni stolpec, določen pri definiranju indeksa. To zagotavlja hitro iskanje in enostaven dostop na podatke tabele.
Primarni ključ tabele je lahko dobra izbira, saj enolično identificira vsako vrstico v tabelah, ne da bi morali dodati dodatne podatke. V nekaterih primerih najboljša izbira Obstajal bo nadomestni primarni ključ, ki ni samo edinstven, ampak tudi majhen in katerega vrednosti se zaporedno povečujejo, zaradi česar so negručasti indeksi, ki temeljijo na tej vrednosti, učinkovitejši. Optimizatorju poizvedb je prav tako všeč ta kombinacija gručastega indeksa in primarnega ključa, ker je združevanje tabel hitrejše od združevanja na drug način, ki ne uporablja primarnega ključa in z njim povezanega gručastega indeksa. Kot sem rekel, je to tekma v nebesih.
Nazadnje pa velja omeniti, da je pri ustvarjanju gručastega indeksa treba upoštevati več vidikov: koliko negručastih indeksov bo temeljilo na njem, kako pogosto se bo spreminjala vrednost stolpca ključnega indeksa in kako velika. Ko se vrednosti v stolpcih gručastega indeksa spremenijo ali indeks ne deluje po pričakovanjih, lahko to vpliva na vse druge indekse v tabeli. Indeks v gručah mora temeljiti na najbolj obstojnem stolpcu, katerega vrednosti naraščajo v določenem vrstnem redu, vendar se ne spreminjajo naključno. Indeks mora podpirati poizvedbe glede na najpogosteje dostopane podatke tabele, tako da poizvedbe v celoti izkoristijo dejstvo, da so podatki razvrščeni in dostopni v korenskih vozliščih, listih indeksa. Če primarni ključ ustreza temu scenariju, ga uporabite. Če ne, izberite drug niz stolpcev.

Kaj če indeksirate pogled, ali je še vedno pogled?

Predstavitev je virtualna miza, ki generira podatke iz ene ali več tabel. V bistvu gre za imenovano poizvedbo, ki pridobi podatke iz osnovnih tabel, ko poizvedujete po tem pogledu. Zmogljivost poizvedbe lahko izboljšate tako, da v tem pogledu ustvarite gručast indeks in negručne indekse, podobno kot ustvarite indekse v tabeli, vendar je glavno opozorilo, da najprej ustvarite gručast indeks, nato pa lahko ustvarite negručastega.
Ko je ustvarjen indeksiran pogled (materializiran pogled), potem sama definicija pogleda ostane ločena entiteta. Navsezadnje je to le trdo kodiran operater IZBERI, shranjeno v bazi podatkov. Indeks pa je povsem druga zgodba. Ko pri ponudniku ustvarite gručast ali negručast indeks, se podatki fizično shranijo na disk, tako kot običajni indeks. Poleg tega se ob spremembi podatkov v osnovnih tabelah samodejno spremeni indeks pogleda (to pomeni, da se boste morda želeli izogniti indeksiranju pogledov na tabelah, ki se pogosto spreminjajo). V vsakem primeru pogled ostaja pogled – pogled na tabele, vendar natančno izveden v ta trenutek, z ustreznimi indeksi.
Preden lahko ustvarite indeks v pogledu, mora izpolnjevati več omejitev. Pogled se lahko na primer sklicuje samo na osnovne tabele, ne pa tudi na druge poglede, te tabele pa morajo biti v isti bazi podatkov. Pravzaprav obstaja veliko drugih omejitev, zato preverite dokumentacijo za SQL Server za vse umazane podrobnosti.

Zakaj uporabljati pokrivni indeks namesto sestavljenega indeksa?

Najprej se prepričajmo, da razumemo razliko med obema. Sestavljeni indeks je preprosto navaden indeks, ki vsebuje več kot en stolpec. Uporabite lahko več ključnih stolpcev, da zagotovite, da je vsak edinstven vrstice tabele, je možno tudi, da je primarni ključ sestavljen iz več stolpcev, da se zagotovi njegova edinstvenost, ali pa poskušate optimizirati izvajanje pogosto klicanih poizvedb v več stolpcih. Na splošno velja, da več ključnih stolpcev kot vsebuje indeks, manj učinkovit bo indeks, kar pomeni, da je treba sestavljene indekse uporabljati preudarno.
Kot rečeno, lahko poizvedba zelo koristi, če se vsi zahtevani podatki takoj nahajajo na listih indeksa, tako kot sam indeks. To ni problem za gručasti indeks, ker vsi podatki so že tam (zato je tako pomembno, da dobro premislite, ko ustvarite indeks v gručah). Toda negručasti indeks na listih vsebuje samo ključne stolpce. Za dostop do vseh drugih podatkov optimizator poizvedb zahteva dodatne korake, ki lahko povzročijo precejšnje stroške pri izvajanju vaših poizvedb.
Tu na pomoč priskoči indeks kritja. Ko definirate negručni indeks, lahko podate dodatne stolpce k svojim ključnim stolpcem. Na primer, recimo, da vaša aplikacija pogosto poizveduje po podatkih stolpcev Številka naročila in Datum naročila v tabeli Prodaja:
IZBERITE OrderID, OrderDate FROM Sales WHERE OrderID = 12345;
V obeh stolpcih lahko ustvarite sestavljen indeks brez gruč, vendar bo stolpec OrderDate samo dodal dodatne stroške vzdrževanja indeksa, ne da bi služil kot posebno uporaben ključni stolpec. Najboljša odločitev bi bilo ustvariti pokrivni indeks na ključnem stolpcu Številka naročila in dodatno vključen stolpec Datum naročila:
CREATE NENCLUSTERED INDEX ix_orderid ON dbo.Sales(OrderID) INCLUDE (OrderDate);
S tem se izognemo pomanjkljivostim indeksiranja odvečnih stolpcev, hkrati pa ohranimo prednosti shranjevanja podatkov v listih pri izvajanju poizvedb. Vključen stolpec ni del ključa, vendar so podatki shranjeni na listnem vozlišču, indeksnem listu. To lahko izboljša zmogljivost poizvedb brez dodatnih stroškov. Poleg tega za stolpce, vključene v pokrivni indeks, velja manj omejitev kot za ključne stolpce indeksa.

Ali je število dvojnikov v ključnem stolpcu pomembno?

Ko ustvarite indeks, morate poskusiti zmanjšati število dvojnikov v ključnih stolpcih. Ali natančneje: poskušajte ohraniti čim manjšo stopnjo ponavljanja.
Če delate s sestavljenim indeksom, se podvajanje nanaša na vse ključne stolpce kot celoto. Posamezen stolpec lahko vsebuje veliko podvojenih vrednosti, vendar mora biti med vsemi stolpci indeksa minimalno ponavljanje. Ustvarite na primer sestavljeni negručasti indeks na stolpcih Ime in Priimek, lahko imate veliko vrednosti John Doe ​​in veliko vrednosti Doe, vendar želite imeti čim manj vrednosti John Doe ali po možnosti samo eno vrednost John Doe.
Razmerje edinstvenosti vrednosti ključnega stolpca se imenuje selektivnost indeksa. Več kot je edinstvenih vrednosti, večja je selektivnost: edinstveni indeks ima največjo možno selektivnost. Mehanizem poizvedb ima zelo rad stolpce z visokimi selektivnimi vrednostmi, še posebej, če so ti stolpci vključeni v člene WHERE vaših najpogosteje izvedenih poizvedb. Bolj ko je indeks selektiven, hitreje lahko poizvedovalni mehanizem zmanjša velikost nastalega niza podatkov. Slaba stran je seveda ta, da bodo stolpci z relativno malo edinstvenimi vrednostmi le redko dobri kandidati za indeksiranje.

Ali je mogoče ustvariti negručasti indeks samo na določeni podnaboru podatkov ključnega stolpca?

Privzeto vsebuje negručasti indeks eno vrstico za vsako vrstico v tabeli. Seveda lahko isto rečete za gručasti indeks, ob predpostavki, da je tak indeks tabela. Ko pa gre za indeks brez gruč, je razmerje ena proti ena pomemben koncept, saj se začne z različico SQL Server 2008, imate možnost ustvariti indeks, ki ga je mogoče filtrirati in omejuje vrstice, vključene v njem. Filtrirani indeks lahko izboljša učinkovitost poizvedb, ker ... je manjše velikosti in vsebuje filtrirane, natančnejše statistike kot vse tabelarične – to vodi k ustvarjanju izboljšanih izvedbenih načrtov. Filtriran indeks zahteva tudi manj prostora za shranjevanje in nižje stroške vzdrževanja. Indeks se posodobi le, ko se spremenijo podatki, ki ustrezajo filtru.
Poleg tega je enostavno ustvariti indeks, ki ga je mogoče filtrirati. V operaterju USTVARI INDEKS morate le navesti v KJE stanje filtra. Na primer, iz indeksa lahko filtrirate vse vrstice, ki vsebujejo NULL, kot je prikazano v kodi:
CREATE NONCLUSTERED INDEX ix_trackingnumber ON Sales.SalesOrderDetail(CarrierTrackingNumber) WHERE CarrierTrackingNumber NI NULL;
Pravzaprav lahko filtriramo vse podatke, ki niso pomembni pri kritičnih poizvedbah. Vendar bodite previdni, saj... SQL Server nalaga več omejitev indeksom, ki jih je mogoče filtrirati, na primer nezmožnost ustvarjanja indeksa, ki ga je mogoče filtrirati, v pogledu, zato natančno preberite dokumentacijo.
Mogoče je tudi, da lahko dosežete podobne rezultate z ustvarjanjem indeksiranega pogleda. Vendar ima filtrirani indeks več prednosti, kot je možnost zmanjšanja stroškov vzdrževanja in izboljšanje kakovosti vaših izvedbenih načrtov. Filtrirane indekse je mogoče obnoviti tudi na spletu. Poskusite to z indeksiranim pogledom.

In spet malo od prevajalca

Namen videza tega prevoda na straneh Habrahabra je bilo, da bi vas povedal ali spomnil na blog SimpleTalk iz RedGate.
Objavlja veliko zabavnih in zanimivih objav.
Nisem povezan z nobenim izdelkom podjetja RedGate, niti z njihovo prodajo.

Kot obljubljeno, knjige za tiste, ki želijo vedeti več
Priporočam tri zelo dobre knjige od sebe (povezave vodijo do vžgati različice v trgovini Amazon):

Načeloma lahko odprete preproste indekse. Dodajte oznake

Osnove Microsoft SQL Server 2012 T-SQL (referenca za razvijalce) Avtor Itzik Ben-Gan Datum objave: 15. julij 2012 Avtor, mojster svoje obrti, daje osnovno znanje o delu z bazami podatkov. Če ste vse pozabili ali nikoli niste vedeli, je vsekakor vredno prebrati.

indeksi ROWID so objekti baze podatkov, ki zagotavljajo prikaz vseh vrednosti v stolpcu tabele, kot tudi ROWID-je vseh vrstic v tabeli, ki vsebujejo vrednosti stolpca.

ROWID je psevdostolpec, ki je edinstven identifikator za vrstico v tabeli in dejansko opisuje natančno fizično lokacijo te določene vrstice. Na podlagi teh informacij Oracle lahko pozneje najde podatke, povezane z vrstico tabele. Vsakič, ko je vrstica premaknjena, izvožena, uvožena ali katera koli druga operacija, ki spremeni njeno lokacijo, se ROWIDčrto, ker zavzema drugačen fizični položaj. Za shranjevanje podatkov ROWID Zahteva se 80 bitov (10 bajtov). Identifikatorji ROWID sestavljajo štiri komponente: številka objekta (32 bitov), ​​številka relativne datoteke (10 bitov), ​​številka bloka (22 bitov) in številka vrstice (16 bitov). Ti identifikatorji so prikazani kot 18-mestna zaporedja, ki označujejo lokacijo podatkov v zbirki podatkov, pri čemer je vsak znak predstavljen v formatu base-64, sestavljenem iz znaki A-Z, a–z, 0–9, + in /. Prvih šest znakov je številka podatkovnega objekta, naslednji trije so relativna številka datoteke, naslednjih šest je številka bloka in zadnji trije so številka vrstice.

primer:

IZBERI fam, ROWID OD študenta;

FAM ROWID

——————————————

IVANOV AAAA3kAAGAAAAGsAAA

PETROV AAAA3kAAGAAAAGsAAB

V bazi podatkov Oracle indeksi se uporabljajo za različne namene: za zagotavljanje edinstvenosti vrednosti v bazi podatkov, za izboljšanje zmogljivosti iskanja zapisov v tabeli, itd. Učinkovitost je izboljšana z vključitvijo sklicevanja na indeksirani stolpec ali stolpce v iskalnih kriterijih za podatke v tabeli. IN Oracle indekse je mogoče ustvariti v katerem koli stolpcu tabele, razen v stolpcih LONG. Indeksi razlikujejo med aplikacijami, ki niso občutljive na hitrost, in visoko zmogljivimi aplikacijami, zlasti pri delu z velikimi tabelami. Preden pa se odločite za ustvarjanje indeksa, morate pretehtati prednosti in slabosti glede delovanja sistema. Učinkovitost se ne bo izboljšala, če preprosto vnesete indeks in pozabite nanj.

Čeprav je največje izboljšanje zmogljivosti posledica ustvarjanja indeksa v stolpcu, kjer so vse vrednosti edinstvene, lahko dobite podobne rezultate za stolpce, ki vsebujejo podvojene ali NULL vrednosti. Za ustvarjanje indeksa ni nujno, da so vrednosti stolpcev edinstvene. Tukaj je nekaj priporočil, ki vam bodo pomagala doseči želeno povečanje zmogljivosti pri uporabi standardnega indeksa, preučili pa bomo tudi težave, povezane z ravnovesjem med zmogljivostjo in porabo prostora na disku pri ustvarjanju indeksa.

Uporaba indeksov za iskanje informacij v tabelah lahko zagotovi pomembne izboljšave zmogljivosti v primerjavi s pregledovanjem tabel, katerih stolpci niso indeksirani. Izbira pravega indeksa pa sploh ni enostavna. Seveda je stolpec, katerega vse vrednosti so edinstvene, boljši za indeksiranje z indeksom B-drevesa, vendar je stolpec, ki ne izpolnjuje teh zahtev, dober kandidat, če približno 10 % njegovih vrstic vsebuje enake vrednosti in nič več. Stolpci »Switch« ali »flag«, na primer tisti, ki hranijo informacije o spolu osebe, niso primerni za indekse dreves B. Stolpci, ki se uporabljajo za shranjevanje majhnega števila »zanesljivih vrednosti«, kot tudi tisti, ki shranjujejo določene vrednosti, prav tako niso primerne, nato pa znaki, na primer »zanesljivost« ali »nezanesljivost«, »aktivnost« ali »neaktivnost«, »da« ali »ne« itd., itd. uporablja se praviloma tam, kjer je nameščen in deluje Oracle Parallel Server in morate povečati raven vzporednosti v bazi podatkov do maksimuma.

Za začetek predlagam, da ugotovite, kaj je to pokrivni indeks, bom podal odlomek iz članka na Habréju:

Zakaj uporabljati pokrivni indeks namesto sestavljenega indeksa?
Najprej se prepričajmo, da razumemo razliko med obema.
Sestavljeni indeks je samo običajni indeks, ki vključuje več kot en stolpec. Uporabite lahko več stolpcev s ključi, da zagotovite, da je vsaka vrstica v tabeli edinstvena, ali pa imate morda več stolpcev, da zagotovite, da je primarni ključ edinstven, ali pa poskušate optimizirati izvajanje pogosto klicanih poizvedb v več stolpcih. Na splošno velja, da več ključnih stolpcev kot vsebuje indeks, manj učinkovit bo indeks, kar pomeni, da je treba sestavljene indekse uporabljati preudarno.

Kot rečeno, lahko poizvedba zelo koristi, če se vsi zahtevani podatki takoj nahajajo na listih indeksa, tako kot sam indeks. To ni problem za gručasti indeks, ker vsi podatki so že tam (zato je tako pomembno, da dobro premislite, ko ustvarite indeks v gručah). Toda negručasti indeks na listih vsebuje samo ključne stolpce. Za dostop do vseh drugih podatkov optimizator poizvedb zahteva dodatne korake, ki lahko povzročijo precejšnje stroške pri izvajanju vaših poizvedb.

To je kje pokrivni indeks hiti na pomoč. Ko definirate negručni indeks, lahko podate dodatne stolpce k svojim ključnim stolpcem.

Tako pokrivni indeks ne sme vsebovati vseh izbirnih stolpcev poizvedbe v drevesni strukturi indeksa, ampak samo tiste, ki bodo uporabljeni za filtriranje ali združevanje podatkov v poizvedbi, preostale stolpce iz razdelka SELECT pa je treba postaviti v VKLJUČITE razdelek kazala.

Morda vam bo v pomoč odgovor na drugo vprašanje.

Zgornji primer namesto pokrivnega indeksa uporablja sestavljeni indeks s tremi polji, koda za ustvarjanje pokrivnega indeksa bi bila videti takole:

USTVARI NEGRUČENI INDEKS NA . ( ASC) INCLUDE (, ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON

Če želite odgovoriti na vaše vprašanje:

za pokrivni indeks vrstni red stolpcev v razdelku INCLUDE ni pomembno, vendar je vrstni red stolpcev pomemben za sestavljeni indeks, Ker Podatki stolpcev so umeščeni v drevo indeksa v vrstnem redu, kot so navedeni stolpci, in optimizator poizvedb ne bo mogel uporabiti indeksa z 2 stolpcema za iskanje vrednosti samo 2 stolpcev. Na sliki lahko vidite jasen primer, kako bo izgledala struktura indeksa 2 stolpcev (EMPLOYEE_ID, SUBSIDIARY_ID).

1) Koncept indeksa
Kazalo je orodje, ki omogoča hiter dostop do vrstic tabele na podlagi vrednosti enega ali več stolpcev.

Ta operater je zelo raznolik, ker ni standardiziran, saj standardi ne obravnavajo težav z zmogljivostjo.

2) Ustvarjanje indeksov
USTVARI INDEKS
VKLOP()

3) Spreminjanje in brisanje indeksov
Za nadzor aktivnosti indeksa se uporablja operator:
SPREMENI INDEKS
Če želite odstraniti indeks, uporabite operator:
SPUSTI INDEKS

a) Pravila izbire mize
1. Priporočljivo je indeksirati tabele, v katerih ni izbranih več kot 5 % vrstic.
2. Tabele, ki nimajo dvojnikov v členu WHERE stavka SELECT, je treba indeksirati.
3. Indeksiranje pogosto posodobljenih tabel ni praktično.
4. Neprimerno je indeksirati tabele, ki ne zavzemajo več kot 2 strani (za Oracle je to manj kot 300 vrstic), saj njihovo popolno skeniranje ne traja dlje.

b) Pravila izbire stolpcev
1. Primarni in tuji ključi – pogosto se uporabljajo za združevanje tabel, pridobivanje podatkov in iskanje. To so vedno edinstveni indeksi z največjo uporabnostjo
2. Ko uporabljate možnosti referenčne integritete, vedno potrebujete indeks na FK.
3. Stolpci, po katerih so podatki pogosto razvrščeni in/ali združeni.
4. Stolpci, po katerih se pogosto išče v stavku WHERE stavka SELECT.
5. Ne ustvarjajte indeksov na dolgih opisnih stolpcih.

c) Načela za ustvarjanje sestavljenih indeksov
1. Sestavljeni indeksi so dobri, če imajo posamezni stolpci malo edinstvenih vrednosti, vendar sestavljeni indeks zagotavlja večjo edinstvenost.
2. Če vse vrednosti, izbrane s stavkom SELECT, pripadajo sestavljenemu indeksu, potem so vrednosti izbrane iz indeksa.
3. Sestavljeni indeks je treba ustvariti, če klavzula WHERE uporablja dve ali več vrednosti v kombinaciji z operatorjem IN.

d) Ni priporočljivo ustvarjati
Ni priporočljivo ustvarjati indeksov na stolpcih, vključno s sestavljenimi, ki:
1. Redko se uporablja za iskanje, združevanje in razvrščanje rezultatov poizvedbe.
2. Vsebujejo pogosto spreminjajoče se vrednosti, kar zahteva pogoste posodobitve index upočasni delovanje baze podatkov.
3. Vsebuje majhno število edinstvenih vrednosti (manj kot 10% m/f) ali prevladujoče število vrstic z eno ali dvema vrednostma (mesto prebivališča dobavitelja je Moskva).
4. Funkcije ali izraz so uporabljeni zanje v klavzuli WHERE in indeks ne deluje.

e) Ne smemo pozabiti
Prizadevati si morate za zmanjšanje števila indeksov, saj njihovo veliko število zmanjša hitrost posodabljanja podatkov. Zato MS SQL Server priporoča ustvarjanje največ 16 indeksov na tabelo.
Običajno so indeksi ustvarjeni za namene poizvedb in za ohranjanje referenčne celovitosti.
Če se indeks ne uporablja za poizvedbe, ga je treba izbrisati in referenčno celovitost zagotoviti s sprožilci.