MySQL INSERT performance

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Nas78
  • Registratie: Januari 2017
  • Laatst online: 25-01-2024
Goeiemorgen,
Ik heb een query in MySQL op basis van een aantal tabellen.
(Bijvoorbeeld "SELECT FROM tableA JOIN tableB")
Deze query levert circa 5000 records op in circa 20 seconden.
Als ik deze records direct in een andere tabel wil wegschrijven
(INSERT INTO tableX .... SELECT FROM tableA JOIN tableB)
dan duurt dat ongeveer 2,5 minuten.
Dat vind ik erg lang.
Terwijl als ik dezelfde records opnieuw zou oppakken vanuit de "tableX" en zou wegschrijven in "tableX"
(INSERT INTO tableX .... SELECT FROM tableX)
dan is dat in 0,2 seconden klaar.
Nou ben ik geen expert en de uren die ik op internet heb besteed hieraan hebben daar niet veel bij geholpen.
Maar ik snap dat grote verschil niet. Die eerste query levert in 20 seconden resultaat. Dat zou dan daarna toch ook in 0,2 seconden moeten kunnen worden overgepompt?
Ben benieuwd wat jullie mij kunnen vertellen hierover.
Alvast bedankt.

Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Als je wat meer informatie zou geven, zoals hoe de tabellen structuur eruit ziet en hoe de queries daadwerkelijk zijn (in code blokken, zodat het ook leesbaar is), dan kunnen we wat meer vertellen over hoe en wat, nu is het vooral theoretisch en kunnen we enkel gissen naar wat de oorzaak zou kunnen zijn.

Ook kun je wellicht met het gebruik van explain wat meer debug informatie krijgen.

Hou er ook rekening mee, dat gelijktijdige lees- en schrijfacties nu ook niet bepaald bevorderend zijn voor de performance.

[ Voor 32% gewijzigd door CH4OS op 17-11-2017 11:38 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Probeer ook eens een transactie om de inserts heen te zetten - zul je zien dat er niet veel van die 2,5 minuten overblijft.

Acties:
  • 0 Henk 'm!

  • Nas78
  • Registratie: Januari 2017
  • Laatst online: 25-01-2024
Mensen, bedankt voor de reacties, ik ben erachter. Ik moet bekennen dat het probleem zat in afwijkende charsets. De ene tabel latin1 en de anders utf8. Dat kost blijkbaar in een SELECT query extra tijd, maar in een INSERT nog veel meer. Voor sommigen logisch, voor mij weer een leerervaring.
Fijn weekend vast.

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Nas78 schreef op vrijdag 17 november 2017 @ 16:47:
Mensen, bedankt voor de reacties, ik ben erachter. Ik moet bekennen dat het probleem zat in afwijkende charsets. De ene tabel latin1 en de anders utf8. Dat kost blijkbaar in een SELECT query extra tijd, maar in een INSERT nog veel meer. Voor sommigen logisch, voor mij weer een leerervaring.
Fijn weekend vast.
Even ter verheldering, het kost niet extra tijd in een SELECT, noch extra tijd in een INSERT.

Het is gewoon een kostenpost om het om te zetten van de ene charset naar de andere en het voorkomt dat je indexen gebruikt etc.
Het is alleen geen extra tijd, als jouw databases zo zijn opgebouwd dan heeft dat gewoon gevolgen en als je erover hebt nagedacht bij het opzetten dan is het ook niet erg want je hebt dan gewoon rekening gehouden met die kosten en je verdient ze ergens anders dubbel en dwars terug.

Wat er waarschijnlijk bovenop nog eens fout gaat is dat je de tabel waarin je het probeert te inserten weer een andere charset is waardoor er nog een conversie extra bovenop komt naast dat je het waarschijnlijk niet in een transactie doet.

Wat jij nu doet is net zoiets als zeggen dat een tractor extra langzaam op de snelweg gaat in vergelijking met een ferrari. Terwijl je gewoon bij aankoop had kunnen kijken naar je doel en daarop je aankoop kunnen aanpassen.

Oftewel jouw probleem is dat je databases zonder nadenken zijn opgezet, tja dan krijg je niet echt een performant iets...

Acties:
  • 0 Henk 'm!

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Nas78 schreef op vrijdag 17 november 2017 @ 16:47:
De ene tabel latin1 en de anders utf8.
Beide geen encodingen die je wil hebben, je wil utf8mb4 (met de laatste versie van utf8mb4_unicode_ci die beschikbaar is). Helaas is dat pas vanaf mysql 8 standaard (die nog niet stable is) en bij MariaDB weet ik niet eens precies hoe het zit. Als je nooit smileys e.d. in je strings hebt, dan merkt je overigens geen verschil totdat je dit wel hebt en vage foutmeldingen krijgt.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

Pagina: 1