Forståelses problemer med dbcc show_statistics.

DBCC SHOW_STATISTICS returnerer selectiviteten på et indeks - ikke hvor tæt data ligger.

Selectiviteten er et udtryk for hvor mange gange hver enkelt værdi forekommer i indekset. Et indeks er i nogle sammenhænge uanvendeligt hvis der er mange ens værdier.

For at se density skal du have fat i DBCC SHOWCONTIG - den returnerer information om hvordan data er pakket i de enkelte pages samt fragmenteringen.

Hvis du kigger i BOOKS ONLINE (installeret sammen med din Query Analyzer og Enterprise Manager) kan du se outputtet fra SHOWCONTIG beskrevet.

Det kan godt være at det er mig der blander begreberne lidt sammen. Det som jeg leder efter er det som du beskriver som selectiviteten, og det havde jeg forstået som den værdi sql serveren returnere under feltet "density" når du kører en dbcc show_statistics. Mit problem er så bare at jeg ikke forstå dens output - som jeg har beskrevet i mit første inlæg. Håber du kan hjælpe mig med det.

Ah, det var mig der blot fokuserede på ordet Density og derfor var på vildspor.

Selectiviteten er ikke den eneste faktor for om det kan betale sig at indeksere.  Du skal have et par andre ting med, muligvis ved du det allerede, men jeg tillader mig lige at docere lidt :-)

Fx. Du har en tabel der indeholder personer og deres køn - M eller K. Hvis du har behov for at lave en betingelse a la WHERE [køn]='M'  - så er der absolut fordel ved at have et indeks på kolonnen, uanset at det altid vil have en dårlig selectivitet. Indekset giver nemlig serveren mulighed for at smide halvdelen af tabellen væk i et hug.

Dernæst - SQL Server lægger indeks og tabel-data på forskellige extents. Det betyder at såfremt din tabel er mindre end 64 KB (eller 128 - kan ikke helt huske), så fravælger SQL Server normalt at bruge indeks. Det vil nemlig kræve flere fysiske læsninger at få både indeks og data op - og en fysisk læsning er dyrere end at lave et tablescan på sådan en lille tabel.

Jeg har en række artikler i artikelsektionen - MsSQL: Performance tuning, part 1-3 - en af dem handler om performancetuning med indeks. De er på et meget grundlæggende niveau, men kan måske hjælpe.

Mht outputtet fra DBCC SHOW_STATISTICS - jeg har faktisk aldrig brugt den, normalt beregner jeg selv spredningen på følgende vis

select count(distinct col) / count(*) from mintabel

Her vil et resultat omkring 1 sige at der er mange unikke værdier i kolonnen ifht antal rækker - mens et lavt resultat (som 1.2539689E-4) siger at der er meget få unikke værdier ifht antal rækker. Fx vil køns-indekset ovenfor normalt kun kunne have unikke 2 værdier for køn uanset antal rækker.

Jeg vil tro at det underlige output du ser hænger sammen med, at DBCC kommandoen kun kigger på statistikkerne - og de opdateres ikke ved hver indsættelse af data. Du kan prøve at køre en UPDATE STATISTICS på din tabel efter hver indsættelse.

Mange tak for dit svar, det var lige noget i den retning jeg havde brug for..