index pe tabela

Întrebări legate de conectarea la alte baze de date relaţionale [PostgreSQL, mSQL, Oracle, Sybase, MS SQL Server] sau despre limbajul SQL în general.

Moderator: Moderatori

Amazing Science
Average Member
Mesaje: 131
Membru din: Dum Oct 15, 2006 7:27 pm

index pe tabela

Mesajde Amazing Science » Mar Noi 25, 2008 2:47 pm

salut!

care e diferenta (din punct de vedere al performantei) daca pe o tabela SQL Server (folosita DOAR pentru citire, nu se scriu date in ea), creez index pe cate un camp sau pe mai multe o data?

adica pot face var.1 asa:

CREATE index idx_unu ON tabela_readonly (camp1)
CREATE index idx_doi ON tabela_readonly (camp2)
CREATE index idx_trei ON tabela_readonly (camp3)
CREATE index idx_patru ON tabela_readonly (camp4)

sau var. 2 asa:

CREATE index idx_toate ON tabela_readonly (camp1, camp2, camp3, camp4)

care e diferenta? care varianta e mai indicata?

mersi.



Avatar utilizator
kleampa
Senior Member
Mesaje: 2774
Membru din: Dum Iul 10, 2005 2:12 pm
Localitate: Bucuresti
Contact:

Mesajde kleampa » Sâm Dec 06, 2008 1:58 am

varianta 2 pentru ca se trimite decat o singura comanda

rremus
New Member
Mesaje: 1
Membru din: Sâm Noi 22, 2008 11:57 pm

Mesajde rremus » Lun Feb 16, 2009 9:08 am

Raspunsul e general pentru orice baza de date relationala, nu doar pentru SQL Server: Depinde de ce interogari ai peste acea tabela.

Orice index poate fi folosit de Query Optimizer (pasul de executie din SQL care aleage planul de acces la tabela, adica alege indexul/indexii care vor fi folosit) daca in query exista un filtru pentru prima coloana din index.

De ex. daca ai un query SELECT ... FROM tabela_readonly WHERE camp2 = 'foo'; acesta poate fi satisfacut doar de un index cu 'camp2' in prima pozitie (idx_doi din exemplul tau). Pentru acest index planul de executie este un 'index seek', adica o probare directa pe valoarea 'foo' care rezulta in citirea a 3-4 pagini de date si nu mai mult. Ceilalti indexi vor rezulta toti in 'index scan, adica o parcurgere a intregului index de la cap la coada care, depinzind de marimea tabelei, rezulta in sute , mii sau si mai multe citiri de pagini de date.

Un index compus (idx_toate din exemplul tau) acesta poate satisface doar cereri care au un filtru pe prima coloana din index ('camp1'). Celelate chei din index (camp2, camp3, camp4) intervin doar daca exista un filtru pe 'camp1' si un filtru suplimentar pe 'camp2'. De ex:
SELECT ... WHERE camp1='foo' AND camp2='bar'; -- Poate folosi idx_toate
SELECT ... WHERE camp2='bar' AND camp3='foobar'; -- NU poate folosi idx_toate
SELECT ... WHERE camp1='foo' AND camp3='foobar'; -- Poate folosi idx_toate dar intr-un mod, dar va trebuii sa faca un scan partial.

Un al doilea criteriu este selectivitatea indexului. Cite valori distincte exista in tabela pentru camp1, pentru camp2, pentru camp3 si pentru camp4? Daca numarul de valori distincte este mic (de ex. este camp2 este numit 'tip_masina' si poate avea 2 valori 'autoturism' sau 'camion') un index pe acest cimp va fi in general ignorat, pentru ca nu ofera nici un avantaj in executia query-ului. Daca ai 1 mil. de inregistrari si jumatate au o valoare in 'camp2', jumatate celalata valoare atunci orice filtru trebuie sa se uite la 500.000 de inregistrari, deci indexul nu aduce nici o imbunatatire.
Deci un index pe un cimp neselectiv nu foloseste la nimic.

Si nu in ultimul rind conteaza care este index-ul 'clustered' al tabelei (evident, ai un index clustred, nu? nu tii datele gramada intr-un heap sper...). Pentru orice alt cimp care trebuie accessat de query (fie ca sa-l returneze la client, fie ca sa satisfaca un filtru) planul de access trebuie sa gaseasca unde este stocat acel cimp (adica in indexul clustered). In general este recomandat ca cel mai folosit plan de access (cel mai des utilizat criteriu de filtrare) sa fie clustered.

Criterii 'secundare' in alegerea unui index sint marimea cheii, pentru ca asta consuma direct spatiu in baza de date, si frecventa de modificare a cheii (cit de des se face UPDATE pe un cimp continut in index).

Daca tabela ar fi read-write ar trebuii sa pui in balanta si cit de mult te costa mentinerea acestor indexi la orice operatiune insert/delete/update.


Înapoi la “Alte baze de date”

Cine este conectat

Utilizatori ce ce navighează pe acest forum: Niciun utilizator înregistrat și 27 vizitatori