Hvordan bruke indekser

[Svish]

Har lest litt om indekser og det virker lurt. Noen er som har noen gode råd og vink?

 

Har jeg skjønt riktig hvis jeg sier at en bør ha en index på alle felter en bruker etter WHERE? for eksempe WHERE user_id = 5? (sånn bortsett fra at user_id vel allerede har en indeks siden den er primary key)

 

og hvis jeg bruker WHERE felt_x=a AND felt_y=b, så burde jeg ha en indeks(felt_x, felt_y) eller no sånt?

Endret 14. mars 2007 av Tussi_qwerty

[Manfred]

Du bør ha indexer på felter du bruker mye til oppslag, og som kan indexeres...

[Svish]

Og "bruker mye til oppslag" vil si det jeg skrev ovenfor?

[roac]

Har jeg skjønt riktig hvis jeg sier at en bør ha en index på alle felter en bruker etter WHERE? for eksempe WHERE user_id = 5? (sånn bortsett fra at user_id vel allerede har en indeks siden den er primary key)

 

og hvis jeg bruker WHERE felt_x=a AND felt_y=b, så burde jeg ha en indeks(felt_x, felt_y) eller no sånt?

8152382[/snapback]

Hvis du ofte gjør slike spørringer, så kan en slik indeks være på sin plass ja.

[Svish]

takk, det var det jeg lurte på ja

[shagg0r]

Du bør ikke overdrive bruken av indekser fordi det fører til at insert, update og delete operasjoner tar mye lengre tid. I tilleg går plassbruken dramatisk opp, men sansynligvis er det vel bare snakk om en liten database uten store datamengder å da har det forsåvidt ikke så mye å si om du bruker indekser eller ikke.

[roac]

Du bør ikke overdrive bruken av indekser fordi det fører til at insert, update og delete operasjoner tar mye lengre tid. I tilleg går plassbruken dramatisk opp, men sansynligvis er det vel bare snakk om en liten database uten store datamengder å da har det forsåvidt ikke så mye å si om du bruker indekser eller ikke.

8159487[/snapback]

Nå tør jeg ikke akkurat tro på at alle databaser er like gode som Microsoft SQL Server på å bruke databaser, men er tabellene små så bør databasemotoren unngå å bruke indekser av seg selv, rett og slett fordi det er mer effektivt å gå rett på tabellen.

[Svish]

har ikke brukt indexer så mye, men har laget index på innlogginga og sjekkingen av innloggingen som skjer hver sidelasting. Tenkte det var lurt. Riktignok ikke så mange brukere enda, men det blir flere etter hvert, og det skjer skrekkelig ofte

[jonvidar]

Har du oracle som database kan du kjøre kommandoen 'explain plan for select ...' Hvis du ser at det brukes 'table access full' så er det lurt å legge inn index på søkefeltet. Uten index vet ikke databasen hvor på disken dataen fins, så da leter den fra punkt a til å. Index sier hvor aktuell data ligger lagret.

[roac]

Har du oracle som database kan du kjøre kommandoen 'explain plan for select ...' Hvis du ser at det brukes 'table access full' så er det lurt å legge inn index på søkefeltet. Uten index vet ikke databasen hvor på disken dataen fins, så da leter den fra punkt a til å. Index sier hvor aktuell data ligger lagret.

8255424[/snapback]

I dette tilfellet, synes dette helt klart å være tilfellet ja, siden man sannsynligvis skal ha ut et begrenset antall rader. Men det er verdt å merke seg at 'table accesss full' ikke nødvendigvis er et onde, det finnes helt klart spørringer hvor det også er den raskeste måten å hente ut dataene på, f eks hvis du skal ha ut en stor andel av dataene. Dette er oftest tilfelle ved små tabeller, men skjer også tidvis ved store mengder data. Grunnen til at jeg trekker dette fram her er at det er noen som har lett for å hevde at 'table access full' eller 'table scan' alltid er et onde, hvilket ikke er tilfelle.

[blackbrrd]

Til pgadmin så er det med en veldig grei funksjon for å visualisere hva som tar tid i en spørring. Den bruker dataene fra EXPLAIN og gjør dem om til piler og symboler.

 

La oss si at du har joinet sammen 10 tabeller og 2 av tabellene har vokst seg gigantiske og mangler indekser, så vil pilen ut fra disse tabellene være gigantiske i forhold til de andre.

 

Som roac sa, det er ikke nødvendigvis dumt av databasen å bruk full table scan, og med pgadmin så er det lett å se HVOR du burde ha indekser.

Endret 19. april 2007 av blackbrrd

[ofredstie]

Har lest litt om indekser og det virker lurt. Noen er som har noen gode råd og vink?

 

Har jeg skjønt riktig hvis jeg sier at en bør ha en index på alle felter en bruker etter WHERE? for eksempe WHERE user_id = 5? (sånn bortsett fra at user_id vel allerede har en indeks siden den er primary key)

 

og hvis jeg bruker WHERE felt_x=a AND felt_y=b, så burde jeg ha en indeks(felt_x, felt_y) eller no sånt?

8152382[/snapback]

 

10 brukere = nei,

100 brukere = nei,

1000 brukere = kanskje

10000 ++ brukere = ja

 

Som mange har allerede sagt så er det ikke slik at "insert index = raskere db", det er en vurderingssak. Avanserte databaser bruker kun en index hvis den faktisk øker uthentingen av data, men tviler på at denne funksjonen er tilgjengelig i MySQL. Hvis du f.eks. har en spørring hvor du skal finne en bruker med fornavn "john" så tviler jeg på at en index vil hjelpe særligt mye (siden spørringen må gå gjennom alle fornavnene i tabellen).

 

Det å si at plassbruken går dramatisk opp ved bruk av index synes jeg er å ta litt hardt i, den vil gå opp men ikke dramatisk (ok, litt avhengig av hva du prøver å indeksere, prøver du å lage en index for en attribute med datatype CHAR(250) i en tabell med tusenvis av innlegg så vil nok indexen bli ganske så stor ja).

 

Hvis databasen din ikke er så veldig stor så tror jeg du oppnår mer ved å dobbelsjekke database-designet og evnt prøve å modifisere denne for å øke hastigheten (f.eks. hvis databasen ikke er særlig normalisert og/eller at du har mange kalkulerte felt i databasen).

[blackbrrd]

Hvis du har en tabell som kun inneholder to ID-er og du har indeks på begge to vil du typisk bruke 50% av plassen på dataene, og 50% på indeksene Slike tabeller er rimelig vanlig ettersom de blir brukt for å løse opp mange-til-mange forhold.