MyISAM ist nicht mehr zeitgemäß – verwendet InnoDB

InnoDB ist seit MySQL 5.5 und damit seit beinahe 15 Jahren die Standard-Engine für MySQL-Datenbanken. MyISAM war zuvor bis MySQL 5.5 üblich, wird nicht mehr aktiv weiterentwickelt, ist aber häufig noch im Einsatz.

Ein früherer Beitrag zu diesem Thema erschien bereits 2017, der ebenfalls auf die Unterschiede und auf die Umstellung eingeht. Titel: InnoDB oder MyISAM
 

Kurzer Überblick der technischen Unterschiede

Sperrmechanismus
– InnoDB verwendet Row-Level-Locking, sperrt nur einzelne Zeilen, wodurch konkurrierende Schreibzugriffe effizienter abgearbeitet werden können.
– MyISAM sperrt stets die komplette Tabelle (Table Lock), was bei parallelen Zugriffen zu Engpässen führen kann.

Transaktionen & Sicherheit
– InnoDB unterstützt ACID-konforme Transaktionen, inkl. Commit, Rollback und automatischer Crash-Recovery.
– MyISAM bietet keine Transaktionen und ist anfälliger für Inkonsistenzen nach Abstürzen.

Fremdschlüssel
– Nur InnoDB unterstützt Foreign Key Constraints zur referenziellen Integrität.
– MyISAM hat diese Fähigkeit nicht.

Volltextsuche
– InnoDB unterstützt FULLTEXT-Indexe „erst“ seit MySQL 5.6.4
– MyISAM bietet integrierte Volltextsuche.

Speicher und Performance
– InnoDB hat höhere „Overhead“-Kosten, optimiert jedoch bei den gemischten Lese-/Schreiboperationen und hoher Parallelität die Performance.
– MyISAM hat einen geringeren Festplatten- und RAM Verbrauch und kann bei rein leselastigen Abfragen Vorteile bieten, z. B. bei COUNT(*)-Abfragen, da die Zeilenanzahl gespeichert wird.
 

Wann ist MyISAM noch sinnvoll?

Fast nie – höchstens für Edge-Cases wie:
– Einzelne Read-Only Tabellen mit extrem hohem Lesezugriff (z.B. alte Suchindizes)
– Spezielle Anwendungsfälle, bei denen keine Transaktionen und keine Gleichzeitigkeit erforderlich sind (große, unveränderte Statistik-Tabellen ohne Transaktionen)

Aber selbst hier ist InnoDB mit Fulltext-Indizes oft schon die bessere Wahl.
 

Klare Empfehlung daher InnoDB

Für moderne Anwendungen, CMS, Shops oder Blogs ist InnoDB in fast allen Fällen die bessere Wahl: Transaktionen, Foreign-Keys, Crash-Recovery und besseres Handling bei parallelen Zugriffen.

Die Mischung von InnoDB und MyISAM wird nicht empfohlen, da JOINs auf MyISAM-Tabellen zu Table-Locks führen können und somit Anfragen erheblich verlangsamen.

Ein solcher Mischbetrieb ist häufig bei alten Installationen von Software der Fall, wenn zwar das Basissystem durch Updates irgendwann auf InnoDB umgestellt wurde, aber ältere Plugins weiterhin noch MyISAM verwenden.

Tabelle einer Datenbank in InnoDB umwandeln vorher ein Backup erstellen:
ALTER TABLE tablename ENGINE=innodb;
 

Einige CMS/Shop-Systeme mit InnoDB als MySQL-Standard

– WordPress + WooCommerce: inzwischen Standard
– Joomla: InnoDB bei modernen Installationen
– Shopware: Pflicht ab neueren Versionen
 

InnoDB bei SpaceHost performanter dank Percona

Bei uns sind leicht veränderte MySQL-Installationen im Einsatz, die vollständig kompatibel mit Standard-MySQL sind. Neben Vorteilen des Managements und der Überwachung für uns als Hoster im Hintergrund, bringen diese v.a. auch Vorteile für Kunden: Percona Server

Percona Server ist ein Fork von MySQL mit Fokus auf Performance, Stabilität, erweitertes Monitoring und Tuning. Dabei setzt Percona auf die Standard-MySQL-InnoDB mit diversen Optimierungen.

Dies erfolgt durch Erweiterung und Optimierung des InnoDB-Codes selbst, um echte Performance- und Stabilitätsverbesserungen zu erreichen. Zu diesen Verbesserungen gegenüber Standard-InnoDB zählen u.a.:
– Pufferverwaltung (Buffer Pool): Verbesserte Algorithmen fürs Caching und Flushing > besserer Durchsatz bei hoher Last
– Crash Recovery: Verbesserte Wiederherstellung nach Abstürzen
– IO Subsystem: Optimierte IO-Scheduling-Strategien für besseres paralleles Lesen/Schreiben
– Adaptive Hash Index: Verbesserungen im Adaptive Hash Index für schnelleren Zugriff
– Locking und Deadlock Handling: Bessere Sperr- und Deadlock-Mechanismen, weniger Wartezeiten