[Magnus_A]

Det lustiga är att jag gör en replace into måltabell select * from källtabell med totalt ca 10 000 rader i tre olika tabellpar och det går på ca 5 sekunder totalt. Men då kör jag inte delayed, eftersom ingen skriver i databasen utom jag.

Frågan är hur mycket du behöver delayed.

Intressant kommentar i Mysql-manualen:

Performance considerations: *Please note that REPLACE INTO is a much slower performer than an UPDATE statement. Keep in mind that a REPLACE INTO requires a test on the keys, and if a matching unique key is found on any or all columns, a DELETE FROM is executed, then an INSERT is executed. There's a lot of management of rows involved in this, and if you're doing it frequently, you'll hurt your performance unless you simply cannot do with any other syntax. *The only time when I can see where you'd actually need a REPLACE INTO is when you have multiple unique constraints on a table, and need to drop any rows that would match any of the constraints. Then REPLACE INTO becomes more efficient from DELETE FROM... INSERT INTO... *If you're looking at a single unique column table (Primary Key), please use UPDATE, or INSERT. Also, check out INSERT ... ON DUPLIATE KEY UPDATE... as an alternative if you're willing to stick to MySQL 4.1+

[eg0master]

Även jag tycker 3min låter väldigt mycket men visst ibland tar det lång tidoch du har ju en väldigt stor tabell...

En work-around är ju att inte uppdatera "en hel dag" som du gör utan uppdatera mindre intervaller för at pådet sättet få fler mindre updates.

[radioaktivitet]

Tack för alla svar. Jag får labba lite med REPLACE och se om jag kan få lite bättre tider.

[Clarence]

Originally posted by radioaktivitet@Feb 19 2009, 15:59
Grejen är att jag redan kör alla uppdateringar mot en temporär kopia.

Ca 10 miljoner rader är orginaltabellen. Det som uppdateras flyttas över till orginaltabellen via update. Ca 3000 rader uppdateras via denna update som är en join mellan den temporära tabellen och orginaltabellen.

Frågan ser ut så här:
UPDATE LOW_PRIORITY ORGTABLE O, TEMPTABLE T SET O.NAME = T.NAME WHERE O.ID = T.ID AND T.UPDATED = CURRENT_DATE

Det spelar nog ingen roll att du kör updates mot en temporär kopia om din query ser ut på det sättet, originaltabellen kommer ändå låsas.

Testa att ta bort joinen från tabellen och istället göra en insert select till en temp-tabell eller en select till applikationen med vad som ska uppdateras först, för att sedan använda denna data vid updaten (stega igenom det om du hämtar det till applikationen, så du slipper monstruöst långa queries). På så sätt bör inte originaltabellen låsas under skrivprocessen mot kopian.

[martine]

Du använder väl antagligen en MyISAM-tabell, kanske det vore värt att prova hur en InnoDB-tabell skulle prestera. Använder du InnoDB så låser databasen bara en rad i taget och SELECT:erna bör kunna rulla på samtidigt (i teorin i alla fall). Har förvisso ingen egen erfarenhet av prestandaskilllnaden MyISAM/InnoDB men det kanske är värt att prova.

Det låter som detta borde kunde vara en lösning på ditt specifika problem men det kan förstås hända att den övriga prestandan i allmänhet går ner istället (InnoDB är ju mer avancerad i sig). MyISAM är perfekt för att mata ut stora mängder data men är dålig på att klara av mycket förändringar.

[radioaktivitet]

Det är möjligt att det skulle lösa mitt problem. Men tabellen är av typen myisam eftersom jag har ett fritextindex på den. Fritextindex fungerar så vitt jag vet inte med InnoDB. Och man kan väl inte köra två tabelltyper samtidigt?

[Clarence]

Originally posted by radioaktivitet@Feb 20 2009, 12:42
Det är möjligt att det skulle lösa mitt problem. Men tabellen är av typen myisam eftersom jag har ett fritextindex på den. Fritextindex fungerar så vitt jag vet inte med InnoDB. Och man kan väl inte köra två tabelltyper samtidigt?

Nej, du kan inte köra två tabelltyper samtidigt. Eller du kan köra två parallella tabeller, en i varje datatyp. Men det skulle bara ge nackdelar då du skulle göra allt 2 gånger.

Med InnoDB får man lösa fritext-sökningar på annat (och för det mesta bättre) sätt, t ex Sphinxse för databasplugin eller Sphinx/Lucene/Ferret/mnoGoSearch för fristående.

Generellt sett är det inte bra att byta till InnoDB om du redan har skrivit en applikation som är testad och utvecklad för MyISAM. Det finns både positiva och negativa egenheter i respektive typ. Att använda båda två parallellt är ännu klurigare då du måste anpassa inställningarna till servern så att den inte swappar i onödan och ändå har såpass bra mängd minne som möjligt för t ex key buffern respektive buffer poolen.

Men sant är att InnoDB väldigt ofta är användbart av den anledningen att den låser på radnivå för skrivoperationer och inte ens sätter delat lås för selects.

[radioaktivitet]

Originally posted by eg0master@Feb 19 2009, 20:56
Även jag tycker 3min låter väldigt mycket men visst ibland tar det lång tidoch du har ju en väldigt stor tabell...

En work-around är ju att inte uppdatera "en hel dag" som du gör utan uppdatera mindre intervaller för at pådet sättet få fler mindre updates.

Jag sitter fortfarande med samma problem som tidigare.

Tänkte försöka mig på att uppdatera i mindre intervaller.

Min fråga ser alltså ut så här idag:

UPDATE ORGTABLE O, TEMPTABLE T SET O.NAME = T.NAME WHERE O.ID = T.ID AND T.UPDATED = CURRENT_DATE

Hur kan jag göra om frågan så att den uppdaterar i chunks? Låt säga 100 rader åt gången.