[MYSQL] Database, combinatie InnoDB MyISAM of geheel?

[kmf]

Ik heb in het weekend de sprong gewaagd naar InnoDB voor mijn forum, dit is puur om te testen aangezien het draaiende op MyIsam alles vrij goed werkt, zelfs met de table locking.

Ik heb hierbij een aantal veel ge-update en grote tabellen omgezet naar InnoDB. Er zijn echter queries die JOINS updates maken met tabellen van het type MyISAM (gebeurt weinig, maar toch)

Ik merk nu dat heel vaak er toch locks aan de gang zijn in de processlist van mysql, maar deze blijven wel zeer lang hangen. Dit kan oplopen tot meer dan 200 processen die zitten te wachten.

De vraag dus, als je innodb of myisam gebruikt, ben je dan gedwongen om de hele DB te gaan aanpassen (of in ieder geval de samenhangende tabellen) of kan een combo goed verlopen?

De keuze voor een combo is vooral omdat na onderzoek InnoDB toch wat slechter presteerd qua select statements dan MyISAM. Voor tabellen die nauwelijks worden geupdate zou ik ook liever dit hebben dan.

[NMe]

Ik kan er zelf niets over vinden en heb er zelf ook geen ervaring mee. Maar ik kom net wel in de documentatie deze passage tegen:

quote: http://sunsite.mff.cuni.c.../InnoDB_restrictions.html

Warning: do NOT convert MySQL system tables from MyISAM TO InnoDB tables! This is not supported; if you do this MySQL will not restart until you restore the old system tables from a backup or re-generate them with the mysql_install_db script.

Misschien is dat de oorzaak?

[ Voor 9% gewijzigd door NMe op 13-06-2005 11:43 ]

[kmf]

ehm. dat zijn de systeem tabellen. Waar mysql z'n rechten en zo in opslaat denk ik. Niet een "normale" DB

[NMe]

Argh, ik lees weer eens maar de helft.

[ripexx]

In principe zal je alle tabellen waar relatief veel inserts en updates plaats vinden moeten voorzien van een InnoDB engine. Omdat deze dan row level locking mogelijk maakt. Zo is het bijvoorbeeld niet direct nodig om bijvoorbeeld de rechten tabel oid te switchen terwijl de message en topic tabellen er wel van zullen profiteren. Verder is het wel handig om te weten welek locks dan blijven bestaan? en welke queries er last van hebben? verder kan je kijken of bepaalde queries er relatief lang over doen door de slow query log aan te zetten.

[djluc]

Is je code verder wel geoptimaliseerd voor InnoDB? In mijn code voor MyIsam tabellen heb ik bijvoorbeeld weleens extra queries staan om te controleren of referenties wel kloppen. Met InnoDB gaat dit automatisch en hoef je slechts op error_nr's te controleren.

[Verwijderd]

Ik zou puur voor het beheer van de database al nooit kiezen voor een gemengd systeem.

Ook dat InnoDB tabellen bij SELECTs wat minder presteren dan MyISAM tabellen is op zich wel logisch. De extra functionaliteit van de InnoDB tabellen moet toch ergens vandaan komen.

Voor de rest kan ik enkel Ripexx napraten

Verder is het wel handig om te weten welke locks dan blijven bestaan? en welke queries er last van hebben?

[Yo-han]

Zet de slow log van MySQL eens aan en mischien je binary update log ook wel. Op die manier kan je zien welke queries blijven hangen en met EXPLAIN kijken of je er wat wijzer van wordt!

[kmf]

Na een aantal dagen en tweaken met de settings is de load weer normaal geworden. De cache voor innodb stond nogal laag, maar de setting van 50-80% van het werkgeheugen zoals aangeraden op mysql zorgde weer voor andere problemen. Nu staat ie op 500MB. 25% van het geheugen en kleine selects, updates en inserts gaan weer lekker soepel. Vergelijkbaar met myisam.

Alleen bij zeer grote queries die een complete tabel moeten uitlezen of in ieder geval 80000 keys kost wel enorm veel tijd met InnoDB. Deze onderhoudsscript die ik eens in de zoveel tijd draai ging onder MyISAM razendsnel, ongeveer 10 secondes zijn ze al bewerkt, maar met InnoDB duurt het wel 3-4 minuten....