Vsa polja, ki se uporabljajo v pogoju združevanja, je treba podati kot indeksna polja.

2. Spoji z virtualnimi tabelami Če poizvedba uporablja povezavo z virtualno tabelo poizvedovalnega jezika 1C:Enterprise (na primer " RegisterAkumulacije.Izdelki.Ostanki()

“) in poizvedba deluje nezadovoljivo, je priporočljivo, da klic virtualne tabele pretvorite v ločeno poizvedbo in rezultate shranite v začasno tabelo. To pomeni, da morate uporabiti isto priporočilo kot v primeru združevanja s podpoizvedbo (glej točko 1).

Dejstvo je, da je virtualne tabele, ki se uporabljajo v poizvedovalnem jeziku 1C:Enterprise, mogoče razširiti v podpoizvedbe, ko jih prevedemo v SQL. To je zato, ker virtualna tabela pogosto (vendar ne vedno) prejme podatke iz več fizičnih tabel DBMS. Če uporabljate združevanje z navidezno tabelo, ga lahko na ravni SQL v nekaterih primerih implementirate kot združevanje s podpoizvedbo. V tem primeru lahko optimizator DBMS izbere neoptimalen načrt na enak način kot pri delu s podpoizvedbo, ki se izrecno uporablja v jeziku 1C:Enterprise.

3. Neusklajenost med indeksi in pogoji poizvedbe

• Pogoji se uporabljajo v naslednjih delih zahteve:<условие>
• IZBERI... OD... KJE<условие>
• POVEZAVA...PO<ВиртуальнаяТаблица>(, <условие>)
• IZBERI ... IZ<условие>

IMATI

• Za vse te pogoje, uporabljene v poizvedbi, morajo obstajati ustrezni primerni indeksi za optimizacijo izbire podatkov glede na pogoje. Poleg tega je primeren indeks tisti, ki izpolnjuje naslednje zahteve: Zahteva 1
• . Indeks vsebuje vsa polja, navedena v pogoju; Zahteva
• 2. Ta polja so na samem začetku kazala; Zahteva 3

. Ta polja so v vrsti, kar pomeni, da polja, ki niso vključena v pogoj zahteve, niso "zagozdena" med njimi;

• Glavni indeksi, ki jih je ustvaril 1C:Enterprise: indeks z edinstvenim identifikatorjem
• (povezava) za vse objektne entitete (imeniki, dokumenti itd.); registrski indeks
• (povezava na dokument) za tabele registrskih gibanj podrejene vpisniku; indeks na obdobje in vrednosti vseh meritev
• za zbirne tabele akumulacijskih registrov;, obdobje indeksa račun in vrednosti

V primerih, ko samodejno ustvarjeni indeksi ne zadoščajo, lahko v konfiguratorju dodatno indeksirate podrobnosti metapodatkovnega objekta. Vendar je treba upoštevati, da ustvarjanje indeksa pospeši postopek iskanja informacij, vendar lahko nekoliko upočasni postopek spreminjanja s strani uporabnika (dodajanje, urejanje in brisanje) v načinu zagona podjetja 1C. Zato je treba indekse ustvarjati zavestno in le, če je natančno znana poizvedba, za katero tak indeks potrebujemo. Ne ustvarjajte indeksov "za vsak slučaj" ali namenoma odvečnih indeksov. Nikoli na primer ne smete dodatno indeksirati prve dimenzije registra, saj je glavni indeks tabele vsot, ki ga platforma samodejno ustvari, primeren za iskanje po vrednosti prve dimenzije.

Konfiguracija opisuje kopični register Izdelki v skladiščih:

Slika 1. Primer strukture registra kopičenja blaga v skladiščih

Platforma 1C:Enterprise bo samodejno ustvarila indeks bilančne tabele tega registra po obdobjih in vseh dimenzijah v vrstnem redu, kot so navedene v konfiguratorju.

Oglejmo si nekaj primerov poizvedb in analizirajmo, ali jih je mogoče optimalno izvesti s to strukturo podatkov.

Zahteva 1

V tem primeru je kršena zahteva 2. V pogoju ni izbora po prvem polju indeksa (Skladišče). Takšna zahteva ne bo optimalno izvedena. Za njegovo izvedbo bo moral strežnik DBMS iterirati (skenirati) vse zapise v tabeli. Čas izvajanja te operacije je neposredno odvisen od števila vnosov v tabeli ostankov registra in je lahko zelo velik (in se bo povečal z večanjem količine podatkov).

Možnosti optimizacije:

• Indeksirajte dimenzijo »Nomenklatura«.
• Dimenzijo »Nomenklatura« postavite na prvo mesto na seznamu dimenzij. Pri uporabi te metode bodite previdni. V konfiguraciji so lahko druge zahteve, ki jih ta zamenjava lahko upočasni.

Zahteva 2

V tem primeru je kršena zahteva 3. Med dimenzijama »Skladišče« in »Kakovost« je v strukturi registra dimenzija »Nomenklatura«, ki ni navedena v zahtevnem pogoju. Tudi ta poizvedba se ne bo mogla optimalno izvesti. Ko se izvede, bo DBMS preiskal prvo polje indeksa, nato pa bo prisiljen pregledati njegov del. Skeniranje bo povzročilo podaljšanje časa izvajanja poizvedbe in blokiranje odvečnih zapisov v tabeli, to je zmanjšanje celotne prepustnosti sistema.

Možnosti optimizacije:

• V zahtevo dodajte pogoj za dimenzijo “Nomenklatura”.
• Iz zahteve odstranite pogoj za dimenzijo »Kakovost«.
• Prenesite "Nomenklaturo" iz meritev v podrobnosti
• Zamenjajte dimenziji »Nomenklatura« in »Kakovost«.

Zahteva 3

V tem primeru zahteve za ujemanje indeksa in poizvedbe niso kršene. To zahtevo bo DBMS izvršil na optimalen način. Upoštevajte, da ni nujno, da se vrstni red pogojev v poizvedbi ujema z vrstnim redom polj v indeksu. To ni težava in bo DBMS normalno obdelal.

4. Uporaba logičnega ALI v pogojih

4.1 Uporaba logičnega ALI v razdelku WHERE poizvedbe

V razdelku WHERE poizvedbe ne smete uporabljati ALI. To lahko povzroči, da DBMS ne more uporabljati indeksov tabel in bo izvajal preglede, kar bo podaljšalo čas izvajanja poizvedbe in verjetnost zaklepanja. Namesto tega bi morali eno poizvedbo razdeliti na več in združiti rezultate.

Na primer zahteva

IZBERI izdelek . Ime OD Imenik . Izdelki KAKO Izdelek KJE Številka artikla = "001" ALIčlen = "002"

je treba nadomestiti z zahtevo

IZBERI izdelek . Ime OD Imenik . Izdelki KAKO Izdelek KJE Številka artikla = "001" |ZDRUŽI VSE |IZBERI IZDELEK . Ime OD Imenik . Izdelki KAKO Izdelek KJE Številka artikla = "002"

4.2. Vpis uporabnikov v več vlog, vsaka z RLS

1 Z RLS (Zapis Raven Varnost) ali omejitev pravic na ravni zapisa - to je nastavitev uporabniških pravic v sistemu 1 Z, ki omogoča ločevanje pravic za uporabnike v kontekstu dinamično spreminjajočih se podatkov.

Če konfiguracija opisuje več vlog s pogoji RLS, potem enemu uporabniku ne smete dodeliti več kot ene takšne vloge. Če je en uporabnik vključen, na primer, v dveh vlogah z RLS - računovodja in kadrovik, potem ko bodo vse njegove zahteve izvedene, bodo pogoji obeh RLS dodani njihovim pogojem z uporabo logičnega ALI. Na ta način, tudi če v prvotni poizvedbi ni pogoja ALI, se bo tam pojavil, ko bodo dodani pogoji RLS. Takšna zahteva se lahko izvede tudi neoptimalno - počasi in s pretiranimi zaporami.

Namesto tega bi morali ustvariti "mešano" vlogo - "računovodja-kadrovik" in registrirati njen RLS tako, da se izognete uporabi ALI v pogoju, ter vključiti uporabnika v to vlogo.

4.3 Uporaba ALI v pogojih povezave

Ni priporočljivo uporabljati logičnega ALI v pogojih povezave, to je v razdelku programske opreme za zahteve. To lahko vodi tudi do izbire neoptimalnega načrta in počasne izvedbe poizvedb. Ni preprostega univerzalnega načina za prepisovanje takšne poizvedbe brez uporabe ALI. Morate analizirati problem, ki ga rešujete, in poskusiti najti drug algoritem za njegovo rešitev.

5.Uporaba podpoizvedb v pogoju združevanja

Ne smete uporabljati podpoizvedb v pogoju združevanja. To lahko vodi do znatne upočasnitve poizvedbe in (v nekaterih primerih) do njene popolne nedelovanja na nekaterih DBMS. Primer poizvedbe, ki uporablja podpoizvedbo v pogoju združevanja:

Zahteva . Besedilo = "IZBERI |OD | Cene. Obdobje B ( | IZBERI NAJVEČ(CeneZadnjiMesec.Obdobje) | IZ REGISTRACIJE Cena KOT CENE PREJŠNJEGA MESECA | WHERE CeneZadnjiMesec.Obdobje< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | In cene zadnjega meseca.Nomenklatura = Preostalo blago.Nomenklatura |) | KJE je preostalo blago. Skladišče = &Skladišče";

V tem primeru se podpoizvedba v pogoju združevanja uporabi za pridobitev tako rekoč "rezine najnovejšega" na koncu prejšnjega obdobja. Poleg tega je lahko obdobje za vsako nomenklaturo drugačno. Priporočljivo je, da takšno poizvedbo prepišete z uporabo začasnih tabel. Na primer, to je mogoče storiti takole:

Zahteva . Besedilo = " // Maksimalni datumi za določanje cen v prejšnjem obdobju za te artikle |IZBERI | Preostali izdelki Nomenklatura AS, | MAXIMUM(Cene.Obdobje) AS Obdobje |KRAJ DatumiPo nomenklaturah |OD | RegisterAkumulacije.BlagoVSkladiščih.Ostanki(...) KOT PreostaliIzdelki | LEVA POVEZAVA RegisterInformacije.Cena AS Cene | Cene programske opreme.Nomenklatura = Preostali izdelki.Nomenklatura IN | Cene.Pika< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | ZGRUPI PO Preostalih izdelkih. Nomenklatura | WHERE je Preostalo blago.Skladišče = &Skladišče; // Izbira podatkov po ceni za najdeno obdobje |IZBERI | Datumi Po nomenklaturah. Nomenklatura AS Nomenklatura, | Cene KOT Cena prejšnjega meseca |FROM DateBy Nomenklature | LEVA POVEZAVA RegisterInformacije.Cena AS Cene | Cene programske opreme.Nomenklatura = Preostali izdelki.Nomenklatura IN | Cene.Obdobje = DatumiPoNomenklaturah.Obdobje " ;

6. Prejemanje podatkov preko pike iz polj sestavljenega tipa

Če poizvedba uporablja vrednost s pikami iz polja kompleksnega referenčnega tipa, bo pri izvajanju te poizvedbe izvedeno združevanje z vsemi objektnimi tabelami, vključenimi v ta kompleksni tip. Zaradi tega SQL naredi besedilo poizvedbe izjemno zapleteno in pri njegovem izvajanju lahko optimizator DBMS izbere neoptimalen načrt. To lahko privede do resnih težav z zmogljivostjo in v nekaterih primerih celo do neuspešne poizvedbe.

Zlasti ni priporočljivo dostopati do podatkov o registratorju registra (na primer »ProductsInWarehouses.Registrar.Date«) itd. V tem primeru ni pomembno, v katerem delu zahteve uporabite atribut, prejet s piko iz polja zapletenega tipa - na seznamu vrnjenih polj, v pogoju itd. V vseh primerih lahko to zdravljenje povzroči težave pri delovanju.

• Pri ustvarjanju polj sestavljenih referenčnih tipov se izogibajte odvečnosti. Določite čim več možnih vrst za dano polje, kot je potrebno. Ne smete po nepotrebnem uporabljati vrst »katera koli povezava« ali »povezava do katerega koli dokumenta« itd. Namesto tega bi morali natančneje analizirati svojo logiko aplikacije in polju dodeliti točno tiste možne referenčne tipe, ki so potrebni za rešitev težave.
• Po potrebi žrtvujte kompaktno shranjevanje za zmogljivost. Če ste v svoji zahtevi potrebovali vrednost, pridobljeno prek sklica, potem lahko to vrednost morda shranite neposredno v ta objekt. Na primer, če pri delu z registrom potrebujete podatke o datumu registrarja, lahko ustvarite ustrezne podrobnosti v registru in mu pri knjiženju dokumentov dodelite vrednost. To bo privedlo do podvajanja informacij in nekoliko (rahlo) povečanja njihovega obsega, vendar lahko znatno izboljša učinkovitost in stabilnost zahteve.
• Po potrebi žrtvujte kompaktnost kode in vsestranskost za zmogljivost. Za izpolnitev določene zahteve pod danimi pogoji praviloma niso potrebne vse možne vrste dane povezave. V tem primeru bi morali omejiti število možnih tipov s funkcijo EXPRESS. Če je ta poizvedba univerzalna in se uporablja v več različnih situacijah (kjer so vrste povezav lahko različne), potem lahko poizvedbo ustvarite dinamično, tako da v funkcijo EXPRESS nadomestite vrsto, ki je potrebna pod temi pogoji. To bo povečalo velikost izvorne kode in jo morda naredilo manj univerzalno, vendar lahko znatno izboljša zmogljivost in stabilnost poizvedbe.

Primer

Ta zahteva uporablja dostop do podatkov registrarja. Registrar je polje sestavljenega tipa, ki lahko sprejme referenčne vrednosti za eno od 56 vrst dokumentov.

Zahteva . Besedilo = "IZBERI | Številka prodajnega registra, | Datum.registra.prodaje, | Nasprotna stranka, | Prodaja. Količina, | Prodaja.Stroški |OD |KJE ...

Besedilo SQL te poizvedbe bo vključevalo 56 levih združevanj s tabelami dokumentov. To lahko pri izvajanju poizvedbe povzroči resne težave z zmogljivostjo. Vendar pa za rešitev te težave ni treba vzpostaviti povezave z vsemi 56 vrstami dokumentov. Pogoji zahteve so takšni, da bodo ob njeni izvedbi izbrana le gibanja dokumentov »Prodaja blaga in storitev« in »Naročila kupca«. V tem primeru lahko bistveno pohitrimo poizvedbo z omejitvijo števila povezav s funkcijo EXPRESS().

Zahteva . Besedilo = "IZBERI | IZBIRA | THEN EXPRESS(Sales.Registrar AS Document.Sales of Goods and Services).Številka | THEN EXPRESS(Sales.Registrar AS Document.Buyer Order).Številka | KONČAJ IZBIRO KOT številka, | IZBIRA | KDAJ Dokument o prodaji blaga in storitev | THEN EXPRESS(Sales.Registrar AS Document.Sales of Goods and Services).Datum | WHEN Sales.Registrar LINK Document.Buyer Order | THEN EXPRESS(Sales.Registrar AS Document.Buyer Order).Datum | KONČAJ IZBIRO KOT Datum, | Nasprotna stranka, | Prodaja. Količina, | Prodaja.Stroški |OD | RegisterAkumulacije.Prodaja KAKO Prodaja |KJE | Prodaja. Dokument POVEZAVA Registrarja. Prodaja blaga in storitev | ALI Prodaja. Dokument POVEZAVE Registrarja. Naročila kupca";

Ta poizvedba je bolj okorna in morda manj splošna (ne bo delovala pravilno v drugih situacijah – kjer so možne druge vrednosti tipa zapisovalnika). Ko pa se izvede, bo ustvarjena poizvedba SQL, ki bo vsebovala samo dve povezavi z dokumentnimi tabelami. Takšna zahteva bo delovala veliko hitreje in stabilneje kot zahteva v izvirni obliki.

7. Filtriranje virtualnih tabel brez uporabe parametrov

Pri uporabi navideznih tabel v poizvedbah morate vse pogoje, povezane s to navidezno tabelo, prenesti v parametre tabele. Ni priporočljivo filtrirati navideznih tabel z uporabo pogojev v razdelku WHERE itd. Takšna poizvedba bo vrnila pravilen (s funkcionalnega vidika) rezultat, vendar bo DBMS veliko težje izbrati optimalen načrt za njeno izvedbo. V nekaterih primerih lahko to privede do napak v optimizatorju DBMS in znatne upočasnitve delovanja poizvedb.

Naslednja poizvedba na primer uporablja razdelek WHERE poizvedbe za izbiro iz navidezne tabele.

Zahteva . Besedilo = "IZBERI | Nomenklatura |OD | RegisterAkumulacije.BlagaVSkladišcih.Ostanki() |KJE | Skladišče = &Skladišče";

Možno je, da bodo kot rezultat izvajanja te poizvedbe najprej izbrani vsi zapisi virtualne tabele, nato pa bo med njimi izbran del, ki ustreza podanemu pogoju. Najbolje bi bilo omejiti število pridobljenih zapisov zelo zgodaj v procesu poizvedbe. Če želite to narediti, morate pogoje posredovati parametrom navidezne tabele.

Zahteva . Besedilo = "IZBERI | Nomenklatura |OD | RegisterAkumulacije.BlagaVSkladiščih.Ostanki(, Skladišče = &Skladišče)";

V skladu z določbami člena 134 zakonika o delu Ruske federacije morajo delodajalci zaposlenim zagotoviti zvišanje plač v zvezi z naraščajočimi potrošniškimi cenami blaga in storitev. Postopek indeksacije (ob upoštevanju mnenja sindikata) je predpisan v kolektivni pogodbi ali lokalnem regulativnem aktu organizacije. V članku strokovnjaki 1C povedo, kako indeksirati kadrovsko tabelo in trenutne tarife tarif zaposlenih v izdaji 3 "1C: Plače in upravljanje osebja 8" (z nadaljnjim ponovnim izračunom povprečnih zaslužkov).

Indeksiranje v "1C: Plače in upravljanje osebja 8" (ed. 3) običajno pomeni dve nalogi:

• indeksacija kadrovske tabele - delna sprememba tarifnih stopenj v kadrovski tabeli (če se uporablja v programu);
• indeksacija trenutnih tarifnih stopenj zaposlenih - zvišanje tarifnih stopenj z nadaljnjim ponovnim izračunom povprečnih plač.

Indeksacija kadrovske tabele je možna, če program "1C: Plače in upravljanje osebja 8" izdaja 3 vzdržuje kadrovsko tabelo s shranjeno zgodovino (zastavice Vzdrževanje osebja in Vzdrževanje zgodovine sprememb kadrovske tabele v nastavitvah - Kadrovska evidenca - Nastavitev kadrovske tabele Zastavice so izbrane).

Indeksacija se izvede v dokumentu Sprememba osebja. Izbira indeksiranih pozicij se izvede z gumbom Spremeni pozicijo. S klikom na gumb Izpolni kazalnike označimo kazalnike, ki so v nastavitvah obračuna plače označeni kot določajoči sestavo skupne tarifne postavke. Vrednosti teh kazalnikov je mogoče indeksirati tako, da jih pomnožimo s koeficientom indeksacije (slika 1).

riž. 1. Indeksacijo kadrovske tabele, za katero so navedene tarifne skupine in razredi (kategorije), morate najprej opraviti Odobritev tarifne skupine (meni Plača - Odobritev tarifne skupine).

Za prikaz sprememb tarifnih postavk za tarifne kategorije v kadrovski tabeli v dokumentu o potrditvi tarifne skupine kliknite na gumb Spremeni kadrovsko tabelo. V tem primeru se dokument Sprememba kadrovske tabele ustvari samodejno. Indeksacija kadrovske tabele v programu ne vodi samodejno do indeksacije plač zaposlenih in ne vpliva na izračun povprečnih plač.

Indeksacija trenutnih tarif tarifnih stopenj zaposlenih

Od različice 3.1.3 v programu 1C: Plače in upravljanje osebja 8, izdaja 3, indeksacija trenutnih tarif tarifnih stopenj zaposlenih ni samo izražena v povečanju tarifne stopnje, ampak se lahko kombinira s spremembami v drugih dajatve, ki določajo sestavo skupne tarifne stopnje. V tem primeru koeficient indeksacije ni določen, ampak se izračuna kot razmerje med novo agregatno tarifno stopnjo in prejšnjo. Indeksacija trenutnih tarif tarifnih postavk zaposlenih se izvede z dokumentom Sprememba načrtovanih časovnih razmejitev (meni Plača - Sprememba plačila zaposlenih - Gumb Ustvari).

Da bi sistem zvišanje tarifnih postavk zaznal kot indeksacijo, tj. nakazal naraščajoči koeficient za izračun povprečne plače, je treba v dokumentu Sprememba načrtovanih časovnih razmejitev nastaviti zastavico Upoštevaj kot indeksacijo plače (sl. 2).

Ta zastavica je v dokumentu na voljo, če je možnost uporabe mehanizmov indeksacije plač omogočena z zastavico Prejemki zaposlenih se indeksirajo (meni Nastavitve - Plače). Z uporabo gumbov Izberi ali Izpolni morate ustvariti seznam zaposlenih, katerih zaslužki so predmet indeksacije. Nato s klikom na gumb Izpolni indikatorje v dokumentu Sprememba plačila zaposlenih se odpre okno, kjer lahko vnesete fiksne vrednosti (Fiksna vrednost – glejte sliko 2) ali preračunate vnaprej izpolnjene z matematičnimi operacijami (Seštej, pomnoži z ), ki označuje na primer koeficient, s katerim je treba pomnožiti plačo, urno postavko ali drug kazalnik, ki določa sestavo skupne tarifne stopnje. S klikom na gumb Odredba o uskladitvi plače se ustvari tiskana oblika odredbe o uskladitvi plač zaposlenih.

V primeru, da podjetje uporablja tarifne skupine, lahko dokument Sprememba načrtovanih stroškov kreiramo s klikom na gumb Spremeni načrtovane stroške v dokumentu Potrditev tarifne skupine (meni Plača - Potrditev tarifne skupine).

oz

Zakaj mora razvijalec 1C "indeksirati" registrske dimenzije in podrobnosti?

- No, imate zahteve! - je rekla baza podatkov in obesila ...

Kratek odgovor na naslovno vprašanje je, da bo to omogočilo hitro izvajanje poizvedb in zmanjšalo negativen vpliv zaklepanja na .

Kaj je indeks?

Optimizacija umestitve indeksa

Kadar obseg tabel ne dovoljuje, da bi se "prilegale" v RAM strežnika, je na prvem mestu hitrost diskovnega podsistema (I/O). In tukaj ste lahko pozorni na možnost postavljanja indeksov v ločene datoteke, ki se nahajajo na različnih trdih diskih.

Podroben opis dejanj http://technet.microsoft.com/ru-ru/knjižnica/ms175905.aspx
Uporaba indeksa iz druge datotečne skupine izboljša delovanje negručastih indeksov zaradi sočasnosti V/I procesov in dela na samem indeksu.
Zgoraj omenjeno obdelavo lahko uporabimo za določitev dimenzij.

Vpliv indeksov na ključavnice

Odsotnost potrebnega indeksa za poizvedbo pomeni ponavljanje vseh zapisov tabele, kar posledično vodi do redundantnih zaklepanj, tj. nepotrebni zapisi so blokirani. Poleg tega dlje kot traja dokončanje poizvedbe zaradi manjkajočih indeksov, daljši bo čas zadrževanja zaklepanja.
Drug razlog za zaklepanje je majhno število zapisov v tabelah. V zvezi s tem SQL Server pri izbiri načrta izvajanja poizvedbe ne uporablja indeksov, ampak preišče celotno tabelo (Table Scan) in blokira celotno tabelo. Da bi se izognili takšnemu blokiranju, je potrebno povečati število zapisov v tabelah na 1500-2000. V tem primeru postane skeniranje tabele dražje in SQL Server začne uporabljati indekse. Seveda tega ni mogoče vedno storiti; številni imeniki, kot so "Organizacije", "Skladišča", "Divizije" itd. običajno imajo malo vnosov. V teh primerih indeksiranje ne bo izboljšalo učinkovitosti.

Učinkovitost indeksa

Že v naslovu članka smo zapisali, da nas zanima vpliv indeksov na uspešnost poizvedb. Torej so indeksi najbolj primerni za naslednje vrste nalog:

• Poizvedbe, ki določajo "ozke" iskalne kriterije. Takšne poizvedbe morajo prebrati le majhno število vrstic, ki ustrezajo določenim kriterijem.
• Poizvedbe, ki določajo obseg vrednosti. Te poizvedbe morajo prebrati tudi majhno število vrstic.
• Iskanje, ki se uporablja pri operacijah povezovanja. Stolpci, ki se pogosto uporabljajo kot povezovalni ključi, so odlični za indekse.
• Iskanje, pri katerem se podatki berejo v določenem vrstnem redu.Če naj bo nabor rezultatov podatkov razvrščen v vrstnem redu indeksa v gručah, potem razvrščanje ni potrebno, ker je nabor rezultatov podatkov že vnaprej razvrščen. Na primer, če je gručasti indeks ustvarjen v stolpcih priimek, ime in aplikacija zahteva razvrščanje po priimku in nato po imenu, potem ni treba dodati klavzule ORDER BY.

Res je, ob vsej uporabnosti indeksov obstaja en zelo pomemben AMPAK - indeks mora biti »učinkovito uporabljen« in mora omogočati iskanje podatkov z manj V/I operacij in količino sistemskih virov. Nasprotno pa obstaja večja verjetnost, da bodo neuporabljeni (redko uporabljeni) indeksi poslabšali zmogljivost zapisovanja podatkov (ker mora vsaka operacija, ki spremeni podatke, posodobiti tudi strani indeksa) in ustvarili presežek prostora v bazi podatkov.

Pokrivanje(za dano zahtevo) se imenuje indeks, ki vsebuje vsa potrebna polja za to zahtevo. Na primer, če je indeks ustvarjen v stolpcih a, b in c in stavek SELECT poizveduje po podatkih samo iz teh stolpcev, je potreben samo dostop do indeksa.

Da bi ugotovili učinkovitost indeksa, lahko približno ocenimo z uporabo brezplačne spletne storitve, ki prikazuje "načrt izvedbe poizvedbe" in uporabljene indekse.