Index hvordan

jeg er enig med dig (og ikke med den wiz)

Indexet som er valgt indikerer nærmest at der har været tale om en select med en order by på alle kolonnerne i selecten, men det har det ikke været?

Nej men jeg kan ikke helt få det til at passe, jeg lavede en test side (asp) og der var ikke forskel på en select, men hvis jeg brugte brugernr,navn,kontantbeholdning i nogle update og insert på siden gik den fra 30 sec. med index på brugernr til 6 sec. hvis jeg havde index på brugernr,navn,kontantbeholdning.
Er det fordi den henter alle de data som den skal bruge i index eller hvorfor er der denne forskel på index (brugernr) og index (brugernr,navn,kontantbeholdning) ?

den kan jo godt bruge et inde på (brugernr,navn,kontantbeholdning) til at
slå op på brugernr

og du har helt ret i at så behøver den jo slet ikke at tilgå data pagen, når
alle felter er i index

sådan lidt ligesom EJB 1.x fat key pattern

jeg har dog aldrig set det brugt i denne sammenhæng før

og jeg er ikke specielt glad for den slags tuning fordi "helt uskyldige" ændringer
i dine queries vil totalt ødelægge din performance

Jeg holder mig til index på where = og order by :-)

Jeg har lige fået 2 GB ekstra RAM i serveren med SQL bruger stadig kun 1,7 GB som den også gjore inden den fik 2 GB ekstra, jeg har sat fixed size til 3,3 GB og min DB er 6,3 GB stor, kan du sige hvorfor den ikke bruger det ekstra RAM?

32 bit windows ?

Bruger du /3GB switchen ?

Ja win 32 bit og ja det var selvfølgelig /3GB der manglede :-)

Lige et sidste spørgsmål ang index :-)

Hvis man har
Index(brugernr)
Index(navn)
Index(kontantbeholdning)

Hvis man laver en SELECT brugernr,navn,kontantbeholdning FROM bruger Where brugernr = t1 and navn = t2)
Så vil den bruge:
Index (brugernr)
Index (navn)
index (kontantbeholdning)

og en SELECT brugernr,navn,kontantbeholdning FROM bruger Where navn = t1 and kontantbeholdning = t2)
vil bruge:
Index(navn)
index (kontantbeholdning)

og det er mest optimalt at have:
Index (brugernr)
Index (navn)
index (kontantbeholdning)
frem for
Index(brugernr,navn)
Index(navn,kontantbeholdning)
fordi den skal rette i 2 index ved en update på navn fremfor en.

Er ovenstående rigtigt?

den foerste SELECT vil vist ikke bruge index paa kontantbeholdning

jeg ville kun bruge index paa enkelt felter medmindre det er felter som konsekvent
altid bruges sammen, fordi ellers ender du med en million indexes

IMHO, så skal man passe rigtigt meget på med den slags "gæt" på hvilke index SQL Server vil anvende og bruge som udgangspunkt for at vælge en løsning. Der er selvfølgeligt nogle åbenlyse tilfælde men hvad der vælges afhænger af flere faktorer og ikke mindst  dens indeks statistik så i udgangspunktet er det ikke muligt at forudsige.

Det du skal gøre er at kigge på nogle Query plans (i query analyzer) for nogle typiske selects og så se hvad SQL Server rent faktisk vælger at gøre og så tage en beslutning omkring hvilke indeks du skal have.

Slutteligt skal du også tage i betragtning hvordan fordelingen mellem update/insert/delete er i forhold til select.

Hvis du på nogen måder har muligheden så mål i stedet for at gætte...

Jeg kan ikke se den helt store grund til forsigtighed.

Man laver nogle index som man udfra queries og data er fornuftige.

Om SQLServer så vælger at bruge dem eller ej kan man jo ikke gøre
noget ved.

Den kan undlade at bruge indexet, men det gør den forhåbentligt kun hvis den mener at
det er hurtigere end at bruge indexet.

Og hvis det er et fornuftigt index, så vil det sikkert blive brugt senere
i en anden query som ligner eller når der kommer mere data i databasen.

SQL Server laver ikke index combines som Oracle kan gøre det. derfor vælger SQl Server det bedste alternativ mellem dine indexes. Havde du en håndfuld indexes med forskellige kombinationer fra din WHERE clause kan du ikke være helt sikker på hvilken der bruges. Det samme er for dens sags skyld gældende hvis du laver DISTINCT udtræk fra basen. Det bedste er altid et index med alle dine kriterier, men det er ikke særligt realistisk, da du typisk vil have mange forskellige udtræk fra samme tabel. Læg dog lige mærke til at hvis du har et index kol_a,kol_b,kol_c så kan dette også bruges hvis du kun sprøger på kol_a aller f.eks kol_a, kol_b. pas på med bare at klaske løs med indexes på dine atbeller, da det pludseligt går for langsomt ved opdatering. men som arne_v siger, det skader ikke at prøve sig frem.

Ok hvis jeg forstår det rigtigt så er en profiler og index tuning wiz.. den lettet måde ellers skal man i gang med den store omgang med at kigge sine select update osv igennem også prøve sige frem til den bedste performance :-)

Jeg plejer gerne at lade profiler oprette en system tabel og lader den stå og registrere alt (over 50msec) indenfor en times tid i "myldretiden". Så kan du dernæst bruge index tuning wizard til at komme med forslag til nye indexes. Læg lige mræke til forbedringsgraden, hvis den ikke er væsentlig, så skal du nok ikke lægge alle indexes på, men i stedet prøve at se på de enkelte forlsag.

Jeg synes bare at index tuning wiz.. ligger mest vægt på select efter at have kørt en profiler og index tuning wiz.. er mine update,insert,delete blevet helt vild langsomme.
Ved i om der er en mærkbar forskel på sql 2000 og 2005 med hastigheden?

Det kan være din fillfactor på tabellerne, hvis den er meget høj kan der ske omrokeringer hvergang du opdaterer, men det kan også være for mange indexes der skal opdateres. Gå ind på hver tabel og se om der er mange index-"dubletter". slet hvad du synes ser forkert ud.