Jag har ett allvarligt problem.

På en av mina sidor finns en tabell med upp mot 1,000,000 rader och jag måste rensa denna ibland för annars går hela sidan sjuuuuuukt segt.

Så min fråga är. Hur gör man för att lösa det? Man måste väll kunna ha 1,000,000 rader i en tabell? Google och dylikt är ju ha 1,000,000,0000,00000,000 (ni fattar poängen) utan några problem.

Problemet uppstår oftast när jag använder JOIN. Tex.

Finns det nån bättre lösning än att använda JOIN?



Tacksam för svar! :)

Hur ser en explain ut för den queryn?

Menar du sånt här?

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE wall ref w_wall,w_writer w_wall 4 const 232079 Using where; Using filesort
1 SIMPLE users eq_ref PRIMARY PRIMARY 4 xxxxx_se.wall.w_writer 1 Using where

?

Min första tanke är att tabellera inte är indexerade korrekt.

Vi har index men det är mycket möjligt att det är fel gjort.

Vi har index så här:

wall.w_id PRIMARY
wall.w_writer INDEX
wall.w_wall INDEX

Jag vet inte hur INDEX funkar då min kollega konfigurerat detta men om någon har något tipps så vore jag jätte tacksam :)

Eftersom inte wall finns med i query förstår jag inte hur de kan komma upp i EXPLAIN.

Beror på att queryn bara var ett exempel.

Det är ju mycket lättare att hjälpa dig om du visar en query som du har problem med.

Okey här kommer ett exakt utdrag:

SELECT
users.user_id,
users.user_nick,
users.user_born,
users.user_sex,
users.user_img_with,
users.user_img,
users.user_last_active,
users.user_class,
wall.wall_date,
wall.wall_text,
wall.wall_id

FROM wall JOIN users ON users.user_id=wall.wall_writer WHERE wall_wall='1700' AND user_active='1' ORDER BY wall_date DESC LIMIT 0, 20;
# Time: 090122 20:57:34
# Query_time: 2 Lock_time: 0 Rows_sent: 20 Rows_examined: 208956

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!

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?

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

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.

Ä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.

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

~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.