Vilken databas pratar vi om?

SQL Server 2000

Jag skulle vilja veta samma sak, fast jag sitter i MySQL. Är det nån stor skillnad?

#3 stora skillnaden är väl att man kan hinta DBMS:en om hur tabellen kommer att användas, dvs vilken Engine det är som ska ta hand om den.

Motsvarigheten hos SQL Server skulle vara fill factor på ett index.

Dock så skiljer det sig åt syntaxmässigt dock.

För SQL Server så är det ganska så viktigt att det index man använder mest är 'clustered', eftersom detta kommer ligga inlineat i tabellen, det finns alltså behövs ingen extra dereferering från ett leef i indexträdet.

Om man filtrerar på två stycken kolumner samtidigt så bör oxo indexet utgöras av bägge kolumner. Likså ifall man sorterar på två fält samtidigt så ska dessa fält ingå i indexet.

 
Man kanske bör tillägga att ifall man sätter ett index på en nyckel (eller unique) så kan datbasservern tillgodogöra sig den informationen i att den inte kommer att finna duplikat.

Kan också passa på att påpeka att det finns en risk att indexen ger problem om man har för många. Frågeoptimeringen blir nämligen mer komplicerad då den i första hand försöker utnyttja existerande index för att snabba upp sökningen.

Finns exempel på databaser som blivit obrukbara på grund av för många index (giftcentralens gamla databas bl.a, har jag hört). Att ställa frågor mot databasen tog runt 10 sekunder. Lite dryga 99% av tiden gick åt till frågeoptimering, medans själva databasfrågan gick hur snabbt som helst.

Lösningen blev att normalisera databasen och ta bort alla index. =P

Jag brukar mest skapa ett index per tabell med alla fält jag kan tänkas vilja filtrera eller sortera på. Det är alltså inte särskilt optimalt egentligen?

Jag skulle verkligen behöva gå en riktigt bra MySQL-kurs, typ på en eller två dagar. Har inte hittat nån som ligger på min nivå dock. Jag vägrar gå en nybörjarkurs.

#6 Man skulle kunna tro att index funkade på det viset. Men tänk på index mer som ett index i en bok, det skulle bli ganska förvirrande om det var sorterat på titel och kapitelnummer samtidig.

Skulle du vilja göra en sökning på kapitelnummer, så vill du ha ett index som är indelat därefter, meddans om du söker i bokstavorning så vill du ha ett index som är indelat efter titel.

Så egentligen skulle man då göra ett index för varje fält man vill kunna sortera/söka på?

Precis.

En varning dock, index kostar i diskutrymme och prestanda, framförallt när man lägger till data, så måste kanske index byggas om.

… och för att upprepa min varning så kan det också försvåra frågeoptimeringen. Har dock ingen aning om hur ofta det verkligen ställer till problem. =P

Det här är väldigt intressant. Tack för tipsen!

#11

Något ska väl våran (Eriks & min) utbildning utmynna i… ;)

Då verkar det som jag tänkt rätt när jag sätter index. Jag brukar ha klustrat index på det som jag absolut oftast filtrerar på. Därefter har jag ett index för de de filter jag vet att jag ofta kommer använda, samt index för den kolumn som jag vet att jag oftast kommer att sortera på.

Utöver det försöker jag vara noga att sätta fälten i WHERE-satsen i samma ordningen som de är i indexet och eventuella oindexerade fält får komma sist i WHERE-satsen.

Det där med att oindexerade fält kommer sist är en ganska så viktig sak. Man vill föröska eliminera så många icke relevanta rader så snabbat som möjligt. Detta för att de följande operationerna exekverar på ett så litet dataset som möjligt.