Korrekt indeksering?

Næsten.

Jeg mener også at du kan lave almindelige indexer på flere felter.

(altså det er ike kun primær nøgle som kan have index på flerefelter)

Både INDEX, UNIQUE og PRIMARY kan indeholde flere felter - og det er så (for UNIQUE og PRIMARY) *kombinationen* af felter som ikke må optræde flere gange.

Forskelle mellem UNIQUE og PRIMARY:
- UNIQUE kan indeksere kolonner med NULL; det kan PRIMARY KEY ikke.
- Du må kun have een PRIMARY - dette er i henhold til SQL standarden. Du må have lige så mange UNIQUE som du vil.

PRIMARY er altså (bortset fra navne-restriktionen) en UNIQUE på en NOT NULL kolonne. Faktisk vil MySQL automatisk sætte det første UNIQUE/NOT NULL index til at være PRIMARY hvis der ikke allerede er defineret en sådan

Bemærk i øvright at MySQL kun kan bruge et indeks hvis *starten* af indekset kan bruges i søgningen. F.eks, kan et indeks på kombinationen (A, B, C) bruges til at lave søgniner på (A, B, C), (A, B) og (A)  -- men ikke f.eks. (B), (C) og (B, C)

arne >
Jeg er ikke helt med? Altså man kan godt sætte INDEX og UNIQUE på mere end et felt?

majkat >
"Du må kun have een PRIMARY - dette er i henhold til SQL standarden"
Jamen alle felter man sætter til PRIMARY bliver jo sådan set til en fælles nøgle?

Du kan godt have et INDEX bestående af flere felter ligesom du kan have en PRIMARY KEY
bestående af flere felter.

Du kan kun have en PRIMARY KEY.

Eksempel:

CREATE TABLE t (
  a INTEGER,
  b INTEGER,
  c INTEGER,
  d INTEGER,
  PRIMARY KEY(a,b)
);
CREATE INDEX ix ON t (c,d);

nå, på den måde :)

men hvad er forskellen så på de to slags??

Der kan kun være en PRIMARY KEY. Der kan være mange INDEX. PRIMARY KEY er
altid UNIQUE. PRIMARY KEY skal være der (i nogen databaser). Kort sagt: PRIMARY KEY er
noget helt specielt.

ok, men jeg er bare stadig ikke helt sikker på hvad et sammensat INDEX er? hvad er forskellen på at lave enkelte nøgler med INDEX og så lave sammensatte? der er vel ikke rigtig nogen forskel?

Umiddelbart vil jeg sige at man kun bruger et index på mere end et felt, hvis
dataene gør at som oftest vil have en kombineret test på dem
(WHERE felt1=X AND felt2=Y) i sine queries.

PRIMARY KEY på mere end et felt kan være nødvendigt for at få noget unikt. Men
jeg vil næsten altid foretrække at smække et ekstra autogenereret id felt på
i stedet for.

ok... tak for hjælpen :)

majkat & arne >
lav et svar

mit

Lige en ting mere? Hvornår kan det svare sig at lave indeksering på en table? Tænker her på >x antal rækker

Det væsentligste kriterie for om et felt skal have et index må være om det
bruges til join eller where betingelse i queries.

Der er selvfølgelig mest nytte af index ved mange rækker.

arne >
ehm...? så må du hellere lige komme med en forklaring til dette: "Det væsentligste kriterie for om et felt skal have et index må være om det
bruges til join eller where betingelse i queries"

Hvor mange rækker skal der så til før det er bevendt? Jeg har tabeller med under 200-300 rækker? Kan det svare sig med indeksering her? :)

Hvis du har en query:

SELECT a,b,c,d,e,f,g,h,i,j FROM t_1 JOIN T_2 ON t_1.a=t_2.f WHERE t_2.j=brugerinput

Så er det oplagt at putte index på t_1.a, t_2.f og t_2.j

Nytten ved index på under 200 rækker er nok lille. Mne jeg ville sætte dem på
alligevel. Lidt har også ret. Og måske komme rder en dag flere rækker i.

mit

mht få rækker -- der er stor sansynlighed for at MySQL simpelt hen ignorerer indexes for tabeller med få rækker - det er hurtigere bare at indlæse tabellen frem for først indekset, så tabellen.

Så i værste fald har du spildt en lille smule diskplads...

Nå, men tak for hjælpen begge to :)