Welche MySQL-Storage-Engine ist besser? MyISAM oder InnoDB? Eine oft gestellte Frage, auf die es keine eindeutige Lösung gibt. MyISAM wird oft als die modernere Engine angesehen, bis zur Version 5.4 war MyISAM auch die Standard-Engine von MySQL; nun ist die oftmals als veraltet beschimpfte InnoDB-Engine die Standard-Engine. Inzwischen haben die Entwickler von InnoDB viele Nachteile ausgebügelt. Aber auch ohne die neue Version der InnoDB-Engine lohnt sich vielleicht ein Umstieg. Einen Fall werde ich hier untersuchen.
Die vorliegende Datenbank ist über 5 GB groß. Sie gehört zu einem umfangreichen Projekt, zu dem mehrere Server, einige Clients und ein öffentliches Webprojekt gehören. Wir untersuchen zuerst einen reinen Datenbankserver im lokalen Netzwerk. MyISAM wurde am Anfang gewählt weil es einerseits bei der Anlage der Datenbank Standard war, andererseits der Fulltext-Index damals nur unter MyISAM möglich war. Inzwischen ist der Fulltext-Index auch unter InnoDB möglich.
Probleme mit der MyISAM-Tabelle
Wer MyISAM-Datenbanken betreibt, die einen größeren Umfang angenommen haben, wird von einer Tabellen-Beschädigung nicht verschont bleiben. Mittels des MySQL-Befehls „CHECK TABLE“ kann die Tabelle jederzeit geprüft, und mit dem Befehl „REPAIR TABLE“ auch wieder repariert werden. Beides kann in der MySQL-Webseite ausführlich nachgelesen werden. Eine korrupte MyISAM-Tabelle ist kein Problem; ärgerlich ist dies dennoch. Zumal das Reparieren der Tabelle je nach Tabellengröße mehrere Stunden in Anspruch nehmen kann. So lange ist die Datenbanktabelle offline.
Performance-Probleme durch gesperrte MyISAM-Tabellen
Fehlermeldungen wie „Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.“ beim Insert oder Update auf MyISAM-Tabellen kommen daher, da die Storage-Engine MyISAM bei Zugriff auf die Tabelle nicht die betreffenden Datensätze sperrt, wie die Storage-Engine InnoDB, sondern gleich die komplette Tabelle sperrt. Greifen mehrere Tasks gleichzeitig speichernd auf eine MyISAM-Tabelle zu, kann es zu einem Timeout kommen. Im hier zu untersuchenden Fall sind mehrere Jobs vorhanden, die leider einige Stunden am Tag gleichzeitig schreibend auf bis zu zwei MyISAM-Tabellen zugreifen. So „kämpfen“ mehrere Tasks um Schreibrechte auf den Tabellen. Der erste gewinnt. Der Zweite wird in eine Warteschlange eingereiht und darf schreiben, wenn der erste Task abgearbeitet wurde. Doch oftmals wird die Schreibanforderung mittels Timeout beendet. Die erste Möglichkeit, dieses Problem zu umgehen, ist den Timeout zu erhöhen.
Ein MySQL-Connection-String sieht ungefähr wie folgt aus:
ConnectionString=data source=mysql;DATABASE=mydatabase;UID=myuser;PASSWORD=mypassword;Connection Timeout=60
Wir können also ein “Connection Timeout” mit angeben. In diesem Connection-String wurde der Timeout bereits auf 60 Sekunden erhöht (wenn dieser Parameter nicht mit angegeben wird, verwendet MySQL den Standard-Timeout).
Im vorliegenden Fall haben alle Tasks diesen Timeout. Dennoch kommt es mehrmals am Tag zu Schreibproblemen. Eine weitere Erhöhung des Timeouts (größer 60 Sekunden) kann nicht die Lösung sein.
Wir suchen also eine Lösung für unser Performance-Problem. Im nächsten Teil werden wir einen Cache ausprobieren: Einfacher MySQL Fehler-Cache für MyISAM Lock Fehler
Alle Artikel aus dieser Serie
MySQL MyISAM: Performance-Probleme auf der Spur
Einfacher MySQL Fehler-Cache für MyISAM Lock Fehler
MyISAM-Tabellen-Locks in Cache abfangen und nacharbeiten