Hej.

Hur bör man tänka när man skall skapa index till sin databas.
Det finns säkert massor med tips och generella "regler" som för det mesta stämmer.

Vilka fallgropar finns det?

Hur testar man ifall indexen gör någon nytta/onytta?

Jag har försökt att läsa mej till information från allehanda källor och lite har väl fastnat, men jag vill höra era synpunkter också, om nån har lust.

Tuning Wizard? Fördelar/Nackdelar?

En konkret fråga har jag...
Skapas index default på nykelfält i SQL-Server?
Har inte fått dett klart för mej.

Tar tacksamt emot allt nyttigt ni kan komma på...
Snälla, var tydliga :-)

//fredda

en grundregel - tänk alltid igenom vilka index som är ett måste för att
snabba upp databasen - det är de enda du bör lägga till. För många
index saktar istället ner, blir samma effekt som att inte ha några.

Indexering är det samma som att du talar om i vilken ordning de ska
söka. Om du tex har en tabell med personnummer (nyckel), namn,
datum personen gift sig m.m. och vet att du ofta kommer söka på
datumet, kan det vara bra att lägga ett index på det.

Testa: genom att kolla hur lång tid frågan tog innan du lade till indexet
respektive efter. Jag hade en fråga som gick 1 minut snabbare tack vare
ett välplacerat index...

Nyckelfälten får ett defaultindex som du inte kan ta bort/göra om.

/Emma

Först och främst ska du tänka på hur databasen används. Är det mycket uppdateringar i den eller är det framförallt läsoperationer som görs i den? Vad är prioriterat? Finns det någon fråga som måste gå riktigt fort, eller finns det någon stor uppdatering som måste gå fort?

Index gör att läsningar går snabbare, men skrivning går långsammare (index kan iofs hjälpa till viss del för att hitta platsen där skrivoperationen ska ske, men eftersom även indexen måste uppdateras så tar det längre tid att skriva för varje index man har). Generella tips är väl att kolumner där man har foreign keys bör indexeras för att snabba upp joins, kolumner som används i where-klausuler bör även de indexeras.

Tuning wizard är ett bra hjälpmedel om man inte har erfarenhet och kunskap att själv veta /se var man behöver index (för det krävs erfarenhet för att verkligen kunna det), men framförallt kan man kanske lära sig en del av den.


PRIMARY KEY skapar automatiskt ett index.

Hej igen.
Tackar så mycket för ovanstående.

En fråga till dock... (2)

Om jag har 2 tabeller:

tbl1:
-id (nyckel)
-name
-address
-tele
-stateId

tbl2:
-id (nyckel)
-state

Anta att jag kör denna fråga ofta:
SELECT * FROM tbl1 WHERE tbl1.stateID = ????

Är det vettigt att lägga ett index på tbl1.stateId?? Eller är det onödigt eftersom tbl2.id är default indexerat.

Om jag fattat allt rätt borde det givetvis vara bra... Eller??

//fredda


EDIT:

Kan man inte skriva typ såhär:

Declare @start
Declare @stop

Set @start = TIMER (??)
exec sp_test
Set @stop = TIMER

SELECT @stop - @start

...
Detta funkar inte, det vet jag. Men principen, hur gör man?
Målet är förstås att se hur lång tid det tog för sp:n att köras.

Jag jämför lite med Timer i ASP.

//f

Nja, eftersom du i frågan inte refererar till tbl2 överhuvudtaget så hjälper inte det indexet. Så ja, det kan vara en idé att indexera den kolumnen. Även om du joinar mot tb2 så är det ju bra, eftersom det är generellt sett bra att indexera foreign key kolumner.

Du kan skriva så här:


Declare @start datetime
Declare @stop datetime

Set @start = getdate()
exec sp_test
Set @stop = getdate()

-- Tidsdifferensen uttryckt som ett datum (från 1900-01-01 00:00:00.000)
SELECT @stop - @start

-- Tidsdifferensen i millisekunder
select datediff(ms, @start, @stop)

Hej.

TACKAR!

Precis som jag trodde då. Hade en liten diskussion med en kollega.
Ville bara kolla med nån som kunde.

Tackar också för kodsnutten du gav mej.

//fredda