[Lando]

Originally posted by WizKid@Jan 25 2009, 23:55
Skapar du ett index som är på wall_wall och wall_date så kommer den gå mycket fortare.

wall_wall hade jag redan men inte wall_date. Det kanske är en bra idé att lägga på gästboken, PM, forum osv också?

ska prova med planket först. tack!

[WizKid]

MySQL kan bara använda ett index åt gången så min tanke var att du skapar ett index som innehåller både wall_wall och wall_date.

[Lando]

Originally posted by WizKid@Jan 25 2009, 23:57
MySQL kan bara använda ett index åt gången så min tanke var att du skapar ett index som innehåller både wall_wall och wall_date.

Hur gör jag detta?

[WizKid]

Hur man skapar index hittar du på: http://dev.mysql.com/doc/refman/5.0/en/cre...eate-index.html

[Conny Westh]

Ett tips är att alla kolumner som finns med i WHERE-satsen MÅSTE vara indexerade eller vara primärnycklar. Alla främmande nycklar bör oxo vara indexerade.

Som WizKid skrev så bör manoptimera indexen efetr den ordning som indexen används i WHERE resp JOIN-satser så att SQL-motorn kan använda optimerade index. Detta är generellt för de flesta relationsdatabaser.

Så fort du frsöker villkora på en kolumn som inte är indexerad får du en table-scan, dvs då måste sql-motorn i genomsnitt söka igenom halva tabellen och läsa 500 000 poster om du har en miljon totalt, därför går det segt.

Har du index så kan du ofta klara dig med ett fåtal diskaccesser.

[Lyx]

Originally posted by WizKid@Jan 25 2009, 23:55
Skapar du ett index som är på wall_wall och wall_date så kommer den gå mycket fortare.

Är det inte bättre att indexera Id't?

[Robert]

Ursprungligen postat av Lyx

Är det inte bättre att indexera Id't?

wall_wall samt wall_date ingår i WHERE samt ORDER BY syntaxen, så de är bra att indexera. WHERE clausen är säkert bättre att indexera då en indexering egenligen är att låta en tabell bli sorterad så databasen enkelt hittar det den söker.

[MRosenson]

Förstår att de handlar om hur man gör i SQL, men vad ja förstod så handlade de om att de blev mycket inlägg i ett klotterplank?
Är de inte smidigare och bättre att göra så att när de är över 200 inlägg så tas de älsta inlägget bort så fort ett nytt postas?

Eller att de sker en automatisk rensning till exempel på söndagar?

En tanke bara!

//Micke

[mrjb]

~200k rader borde inte vara några problem efter att du fixat de index som förslagits här, men säg att den siffran tio- eller hundradubblas och du inte vill städa tabellen på inlägg, kan det vara värt att titta på nåt som kallas för "horizontal partitioning".

I korthet innebär det att du delar upp en jättestor tabell i flera mindre tabeller, där applikationen utifrån en gemensam nämnare väljer vilken tabell som ska läsas ifrån. MySQL 5.1 har inbyggt stöd för detta till och med om du inte vill koda eget.