[Spindel]

Ja, eftersom för många INDEX kan försämra prestandan vill jag bara vara säker på att jag gör rätt. Alla tabeller i databasen har ID med primary key och index. Som jag har förstått så kan det vara bra att lägga till INDEX när man ofta kör WHERE-frågor mot just den kolumnen.

Låt säga att jag har en url:

http://domain.com/nyhet/nyhetens-rubrik/

SQL-frågan blir ju då SELECT ... WHERE rubrik = "nyhetens-rubrik".

Jag antar att jag bör lägga till INDEX på "rubrik"-kolumnen?

[ChSu]

Bästa sättet att veta: Benchmarks

Själv använder jag postgresql och ger mig på det mesta med
EXPLAIN ANALYZE innan jag lägger till index för att de kan
vara bra i teorin.

[WizKid]

EXPLAIN finns i MySQL och är väldigt smidigt för att se vad som händer. Tyvärr inte lika smidig som i postgresql om jag minns rätt, men man får i alla fall information om vilka index som används eller inte och hur frågan ställs.

Att ha för många index har jag aldrig varit med om. Har precis som du hört att det kan vara problem men aldrig stött på det. Men det är ju bara vid UPDATE/INSERT/REPLACE som det kommer gå långsammare så har man 99% SELECT:s så kvittar det nog hur många index du har.

[grazzy]

Ja.

Index försämrar inte prestandan drastiskt vid läsningar, däremot vid skrivningar. Om du har mycket inserts och updates kan det vara värt att fundera extra mycket på hur många index du har. Om främst är läsningar spelar antalet index mindre roll (även om det inte är bra att använda för mkt disk heller - det blir fler läsningar på disk med fler index...).

Tänk på att du ibland (vet inte hur det är i postgresql) kan specifiera hur många tecken indexet skall bry sig om innan det gör över till vanligt fritext sök. Tex när man pratar om namn brukar man säga att 5-7 tecken är allt man behöver indexera, efter de teckena är det såpass få namn som är lika att fritext-sökning går lika bra. Detta beror på vad för typ av data du indexerar.

Jag blev lite osäker så jag gjorde ett test. Jag skapade en tabell med 50000 10 teckens-slumpmässiga strängar. Sedan gjorde jag ett par helt ovetenskapliga selects mot den med en sträng jag visste fanns i den (på det sättet som du visade med = istället för LIKE). Detta var i mysql 4.1.1 på en p3a, det tog i snitt 0.06 sec att hämta en rad. (Ja, jag använde SQL_NO_CACHE).

När jag lagt till indexet så tog det var helt plötsligt medianresultatet nere på 0.00 sec. Helt klart märktbart resultat alltså.

[kullervo]

Originally posted by grazzy@Jan 8 2008, 20:29
Tänk på att du ibland (vet inte hur det är i postgresql) kan specifiera hur många tecken indexet skall bry sig om innan det gör över till vanligt fritext sök. Tex när man pratar om namn brukar man säga att 5-7 tecken är allt man behöver indexera, efter de teckena är det såpass få namn som är lika att fritext-sökning går lika bra. Detta beror på vad för typ av data du indexerar.

Det finns inte så mycket magi i postgresql som talar om vad man kan och inte kan göra utan det är mer... ehum... naturlagarna som sätter begränsningarna. Vill du bygga ett index över början av en sträng så bygg indexet över substring().

[coredev]

Tjena Spindel.

När tjänar man på att skapa ett index? En tumregel är att du har över några hundra rader i tabellen. Annars är förtjänsten i princip omärkbar / minimal.

Vad förlorar du på att skapa ett index? Tja.. Inserts och Updates kan ta något längre tid. Men för att märka det så gissar jag att du bör ha över 10.000 rader i din tabell.

Det bästa du kan göra är att gå in i PgAdmin III och öppna ett SQL-fönster. Väl där kör du frågan SELECT ... WHERE rubrik = "nyhetens-rubrik". ett antal gånger. Sedan skapar du ditt index.

Nu när du väl har skapat ditt index kör du din SQL-fråga igen och jämför svarstiderna (står längst ner till höger i SQL-rutan i PgAdmin III).