[mySQL] Traag met veel INSERTs

[Verwijderd]

Ik heb een script dat een heleboel informatie insert of update, ongeveer tussen de 1500 en 2500 inserts / updates per keer. Het is verdeeld over 2 tabbelen, die beiden bestaan uit een paar rijen (varchars en ints).

Met een lege tabel (MyIsam), gaat het in 2 seconden. Met 20k aan rijen gaat het al ruim 1 minuut duren.

Ik controleer dus eerst met een select of de informatie die ik invoer al bestaat en daarna bepaal ik dus een insert of een update. Is hier wat aan te verbeteren?.

En wat voor dingen kan ik doen om te zorgen dat mijn tabel sneller gevuld word.

[whoami]

Het is die select die de hele boel vertraagt. Ik dacht dat MySQL zo'n onorthodoxe INSERT_OR_UPDATE statement ofzo had. (INSERT .. ON DUPLICATE KEY UPDATE [zoek ff in de MySQL doc's])

Verder: heb je wel goede indexen ? Een index kan een select behoorlijk versnellen, maar vertraagt dan weer een update/insert (maar da's maar gering); ik vermoed zowiezo dat je vertraging te maken heeft met je SELECT.

[ Voor 9% gewijzigd door whoami op 13-04-2006 21:53 ]

[Verwijderd]

whoami schreef op donderdag 13 april 2006 @ 21:53:
Het is die select die de hele boel vertraagt. Ik dacht dat MySQL zo'n onorthodoxe INSERT_OR_UPDATE statement ofzo had. (INSERT .. ON DUPLICATE KEY UPDATE [zoek ff in de MySQL doc's])

Verder: heb je wel goede indexen ? Een index kan een select behoorlijk versnellen, maar vertraagt dan weer een update/insert (maar da's maar gering); ik vermoed zowiezo dat je vertraging te maken heeft met je SELECT.

Ja, maar ik heb dus een ID, deze staat er als key, maar hij kijkt naar een bepaalde titel of die al bestaat of niet. En zojah doet hij de update over dat ID heen, de ID verkrijg ik dus via een SELECT. Hoe kan ik zorgen dat ik die select alsnog weg kan halen en wel over de zelfde rij heen schrijf?

[Verwijderd]

[quote]Verwijderd schreef op donderdag 13 april 2006 @ 22:12:
[...]

[ Voor 71% gewijzigd door Verwijderd op 13-04-2006 22:43 ]

[Gomez12]

Verwijderd schreef op donderdag 13 april 2006 @ 22:12:
[...]


Ja, maar ik heb dus een ID, deze staat er als key, maar hij kijkt naar een bepaalde titel of die al bestaat of niet. En zojah doet hij de update over dat ID heen, de ID verkrijg ik dus via een SELECT. Hoe kan ik zorgen dat ik die select alsnog weg kan halen en wel over de zelfde rij heen schrijf?

Mogelijk verbetering :
Splits je script in 3 delen
a : kijk wat er al in staat 1 query met subquery,
b : zet de indexen uit. en insert alles wat niet onder a valt, zet hierna de indexen weer aan.
c : update alles uit a.

Hiermee voorkom je het de hele tijd wel en niet gebruiken van indexen die je hebt als je het per regel gaat controleren.

optie 2 :
maak van je begintabel een tijdelijke tabel.
Insert alles in een 2e tijdelijke tabel zonder indexen.
outer join de 2 tijdelijke tabellen naar een nieuwe begintabel.

Hierbij kan je dbase alle functionaliteit die het heeft gebruiken, maar of dit de moeite waard is voor 2500 records???

Je moet gewoon onthouden dat je zoveel mogelijk in batches moet doen, niet regel voor regel.

[pjonk]

Grote batches kun je ook heel snel importeren via een LOAD DATA INFILE query, zie:
http://dev.mysql.com/doc/refman/5.0/en/load-data.html

En plaats bijv. al je te importeren records in een tijdelijke tabel en JOIN deze met de bestaande tabel dan kun je heel makkelijk en snel bepalen welke rijen nieuw zijn en welke niet.

[ Voor 6% gewijzigd door pjonk op 14-04-2006 14:59 ]

[yiko]

Verwijderd schreef op donderdag 13 april 2006 @ 22:12:
[...]


Ja, maar ik heb dus een ID, deze staat er als key, maar hij kijkt naar een bepaalde titel of die al bestaat of niet. En zojah doet hij de update over dat ID heen, de ID verkrijg ik dus via een SELECT. Hoe kan ik zorgen dat ik die select alsnog weg kan halen en wel over de zelfde rij heen schrijf?

Als je telkens zoekt op titel, stel ik voor om ook daarop een index te leggen. Zal al veel schelen qua snelheid.

[ACM]

Worden tijdens die select ook inserts/updates gedaan? Zoja, overweeg dan het innodb-tabelformaat, myisam gebruikt voor het schrijven/lezen volledige table-locks. Bij een lezer/schrijver is dat niet erg en versnelt het zelfs de boel door zijn eenvoud. Maar zodra er een lezer actief is moeten de schrijvers nog wachten tot die klaar zijn, bij een schrijver is het nog erger want alle processen moeten daarvoor wachten.

Als je echter maar een proces tegelijk op die tabel actief hebt, dan is dat niet relevant voor je en zul je het hoogst waarschijnlijk in de indexering moeten zoeken. Het verminderen van het aantal statements door die insert-of-update syntax te gebruiken is ook nuttig, maar dat is minder significant gok ik dan de indexen in orde hebben.

Verwijderd schreef op donderdag 13 april 2006 @ 22:12:
Ja, maar ik heb dus een ID, deze staat er als key, maar hij kijkt naar een bepaalde titel of die al bestaat of niet. En zojah doet hij de update over dat ID heen, de ID verkrijg ik dus via een SELECT. Hoe kan ik zorgen dat ik die select alsnog weg kan halen en wel over de zelfde rij heen schrijf?

Is dat niet iets waar je een unique index op moet leggen dan? Daar werkt die insert-of-update constructie ook mee, maar zo te lezen zal een index daar op sowieso al flink helpen. Tenzij je een like-search doet die begint met een wildcard.

[ Voor 31% gewijzigd door ACM op 14-04-2006 22:51 ]