Lidt i tvil om index'er

En primary key skal unik identificere rækken.

Den kan godt bestå af fere felter, men hvsi det kan undgåes så gør det.

Hvis du vil lave en anden kolonne unik, så kan du sætte et unikt index på den.

Almindelige index sætter du på, når du vil kunne søge hurtigt i kolonnen.

ja... Det er nok mig der har formuleret mig dårligt..

Jeg tænkte mere i retning af at et Index kan indeholde flere felter.

F.eks.

felter
------
a b c d e f

Primary Key, a
index mitindex=b,c,d,e,f

fremfor

Primary Key, a
index mitindex1=b
index mitindex2=c
index mitindex3=d
index mitindex4=e

Kan ikke helt lure forskellen. Formentlig har det noget at gøre med at løsning1 kun er smart hvis der skal selectes noget hvor det som SELECTES ligger til "venstre" for WHERE, a'la

SELECT b,c,d,e FROM tabel WHERE f=n

Formentlig fordi db enginen aligevel skal læse nedaf/venstre->højre..

.... Kan ikke lige helt sætte det ind i min samlede forstilling om hvordan det fungerer :o)

Du kan godt lave et index på flere kolonner.

Men jeg er 98% sikker på at du ikke vil.

Hvis du laver et index på b og c, så hjælper det kun på
queries med en WHERE b=x AND c=y - det hjælper ikke på
en query WHERE c=z overhovedet.

Multi felt index er kun relevant hvis felterne hører meget tæt sammen.

med mindre man "driller" databasen lidt: WHERE (b is not null or b is null) and c=z

Hvis man vil optimere en given sql-forespørgsel imod et konkret index, så (afhængig af database) kan man tvinge parseren til at bruge et konkret index vha. ovenstående.

Og der er ikke noget i vejen for:

Primary key, a
index mitindex=a,b,c

lap> Synes du er lidt uenig med arne_v

Hvorfor er løsning1 ligeså god som løsning2 eller måske endda bedre? Kan jeg lokke dig til at forklare det til en SQL nybegynder?

jeg tror egentlig, at arne_v og jeg er ret enige - det er blot niveauet vil ikke er helt enige om :-)

Indexes har flere forskellige formål. Et index bliver brugt for at sikre uniq-nes - f.eks. på en nøgle/primary key - hvilket du egentlig spørger til her.

Men index bruges også til at optimere opslag i databasen (læs: søgninger). Lige præcis på dette område er der meget stor forskel på de forskellige databaser, men som tommelfinger regel, så vil en søgning først finde records vha. et index - det som "passer" bedst på afgrænsningerne (se mit eksempel).

Hvis du laver enkeltindexes på kolonnerne (lige gyldigt om det er uniq eller ej), så vil en kombineret søgning aldrig kunne finde et index, som kan bruges. Derfor vil søgningen blive sløvet ned i forhold til et kombineret index.

Håber det forklarer det - ellers prøver vi bare igen :-)

Lap> Lige prcis anden sidste sætning fik mig til at forstå (tror jeg)

Så hvis jeg har behov for en masse SELECT a 'la

SELECT * from tabel where a=10 AND b=20 and c=30

så vil det være mest optimalt at lave et index og kobinere disse 3 i samme index.

Hvis jeg deriomod laver enkelte index'er på a, b og c, vil det stadig være hurtigere, men ikke så hurtigt som det kombinerde index.

Er jeg på rette spor?

p.s. jeg har triplet point til jer, som tak for hjælpen indtil videre.

ja, de 3 eller eventuelt alle 4 hvis der er mange records i tabellen. Hvis du har et index over alle 4 kolonner, så skal man aldrig have fat i selve tabellen - og det er en fordel, hvis der er mange records - eller der er mange kolonner.

Formentlig vil det være hurtigere med enkelte indexes - afhængig af database, men det kan gøres hurtigere, så ja, du er på rette spor.

Points har nu ikke den store betydning.

Jamen så får du lidt god karma istedet :) Tak for hjælp..

Men synes nu i skal oprette svar aligevel.

velbekomme - og skyd du blot points til arne_v :-)

Jeg vil ligge et svar

svar

tak for hjælpen.