InnoDB vs. MyISAM: Unterschiede, die noch relevant sind

1. Warum der Vergleich heute noch relevant ist

Seit MySQL 5.5 ist InnoDB die Standard-Storage-Engine, und in neuen Projekten kommt MyISAM praktisch nicht mehr zum Einsatz. Trotzdem begegnet man MyISAM-Tabellen regelmäßig in gewachsenen Systemen: alte Magento-1-Installationen, migrierte WordPress-Datenbanken, selbstgebaute Reporting-Tools aus den 2000er-Jahren oder schlicht Tabellen, die vor Jahren mit CREATE TABLE ... ENGINE=MyISAM angelegt und nie migriert wurden. Der Vergleich InnoDB vs. MyISAM ist deshalb kein historisches Thema, sondern eine praktische Notwendigkeit für jeden, der mit Legacy-Datenbanken arbeitet.

Die Unterschiede zwischen den beiden Engines sind nicht kosmetisch, sondern betreffen fundamentale Eigenschaften: ob eine Datenbank Transaktionen unterstützt, wie granular Sperren gesetzt werden und ob ein Systemabsturz zu Datenverlust führt. Wer eine MyISAM-Tabelle in Produktion übersieht, kann von diesen Eigenschaften böse überrascht werden, etwa wenn ein einzelner langsamer Schreibzugriff die komplette Tabelle für alle anderen Anfragen blockiert. Die folgenden Abschnitte arbeiten die Unterschiede zwischen InnoDB und MyISAM systematisch auf.

2. Transaktionen und ACID: der fundamentale Unterschied

InnoDB ist eine vollständig transaktionale Storage-Engine und erfüllt die ACID-Eigenschaften: Atomicity, Consistency, Isolation, Durability. Mehrere zusammenhängende Änderungen lassen sich in einer Transaktion bündeln und entweder komplett übernehmen oder komplett zurückrollen. MyISAM kennt dieses Konzept überhaupt nicht. Ein ROLLBACK auf eine MyISAM-Tabelle hat keine Wirkung, weil MyISAM keine Undo-Informationen führt. Jede einzelne SQL-Anweisung wird sofort und dauerhaft angewendet, unabhängig davon, ob eine nachfolgende Anweisung fehlschlägt.

Für Anwendungen, die mehrere zusammengehörige Schreiboperationen ausführen, etwa das gleichzeitige Anlegen einer Bestellung und das Reduzieren des Lagerbestands, ist das ein erhebliches Risiko. Schlägt bei MyISAM die zweite Operation fehl, bleibt die erste bestehen, und die Datenbank gerät in einen inkonsistenten Zustand, der manuell korrigiert werden muss. Bei InnoDB verhindert die Transaktion genau dieses Szenario, weil COMMIT beide Änderungen zusammen bestätigt oder ROLLBACK beide zusammen verwirft.

-- InnoDB: transaction guarantees atomicity across multiple statements
START TRANSACTION;
UPDATE inventory SET stock = stock - 1 WHERE product_id = 4711;
INSERT INTO orders (product_id, customer_id, status) VALUES (4711, 88, 'new');
COMMIT;
-- If either statement fails, ROLLBACK undoes both changes cleanly

-- MyISAM: no transaction support, ROLLBACK has no effect
-- START TRANSACTION; ... ROLLBACK;  -- silently ignored on MyISAM tables

-- Check which engine a table actually uses
SELECT table_name, engine
FROM information_schema.tables
WHERE table_schema = 'shop_db' AND table_name = 'inventory';

3. Locking-Granularität: Row-Level vs. Table-Level

Der zweite fundamentale Unterschied liegt in der Sperrgranularität. InnoDB setzt Row-Level-Locks, sperrt also nur die tatsächlich betroffenen Zeilen einer Tabelle. Zwei Transaktionen können gleichzeitig unterschiedliche Zeilen derselben Tabelle ändern, ohne sich gegenseitig zu blockieren. MyISAM hingegen kennt nur Table-Level-Locks. Sobald ein Schreibzugriff auf eine MyISAM-Tabelle erfolgt, wird die gesamte Tabelle gesperrt, auch für Lesezugriffe, bis der Schreibvorgang abgeschlossen ist.

In der Praxis bedeutet das: Bei hoher Nebenläufigkeit mit vielen gleichzeitigen Schreibzugriffen skaliert MyISAM deutlich schlechter als InnoDB. Ein Onlineshop mit tausenden gleichzeitigen Bestellungen würde bei MyISAM-Tabellen für Bestellungen oder Lagerbestand zu einer Warteschlange von blockierten Schreibzugriffen führen, weil jede Bestellung die komplette Tabelle sperrt. InnoDB umgeht dieses Problem durch Row-Level-Locking in Kombination mit MVCC, Multiversion Concurrency Control, das Lesezugriffe sogar komplett ohne Sperren ermöglicht.

-- Inspect current locks held by InnoDB transactions
SELECT
    engine_transaction_id,
    object_schema,
    object_name,
    lock_type,
    lock_mode,
    lock_status
FROM performance_schema.data_locks
WHERE object_schema = 'shop_db';

-- MyISAM: no row-level lock info exists, only table-level lock status
SHOW OPEN TABLES WHERE In_use > 0;

-- Demonstrate the blocking effect: a write on MyISAM blocks all readers
-- Session A: LOCK TABLES legacy_stats WRITE;
-- Session B: SELECT * FROM legacy_stats;  -- blocks until Session A unlocks

4. Crash Safety und Datenintegrität

Die Crash Safety unterscheidet InnoDB und MyISAM massiv. InnoDB nutzt Write-Ahead Logging über das Redo Log: Jede Änderung wird zuerst im Redo Log persistiert, bevor sie in den eigentlichen Datenseiten landet. Stürzt der Server ab, spielt InnoDB beim nächsten Start das Redo Log automatisch ein und stellt einen konsistenten Zustand wieder her, ohne manuelles Eingreifen. Diese Eigenschaft macht InnoDB für praktisch jeden Produktionseinsatz zur einzig sinnvollen Wahl.

MyISAM bietet keinen vergleichbaren Mechanismus. Ein Systemabsturz während eines Schreibvorgangs kann eine MyISAM-Tabelle in einem beschädigten Zustand hinterlassen, der oft nur mit REPAIR TABLE oder dem externen Tool myisamchk behoben werden kann, und das nicht immer ohne Datenverlust. Bei großen Tabellen kann dieser Reparaturvorgang zudem lange dauern, während die Tabelle für den produktiven Betrieb nicht verfügbar ist. Diese Eigenschaft allein disqualifiziert MyISAM für jede Anwendung, bei der Datenverlust nicht akzeptabel ist.

-- Check and repair a MyISAM table after a suspected crash
CHECK TABLE legacy_reports;
REPAIR TABLE legacy_reports;

-- InnoDB requires no manual repair: crash recovery runs automatically
-- at startup by replaying the redo log up to the last checkpoint.
-- Verify recovery happened cleanly via the error log:
-- grep "InnoDB: Starting crash recovery" /var/log/mysql/error.log

5. Volltextsuche: von MyISAM zu InnoDB FULLTEXT

Lange Zeit war die Volltextsuche eine der wenigen Domänen, in denen MyISAM einen klaren technischen Vorteil gegenüber InnoDB hatte. Bis MySQL 5.5 unterstützte ausschließlich MyISAM FULLTEXT-Indizes, weshalb viele ältere Anwendungen für Suchtabellen bewusst auf MyISAM setzten, selbst wenn der Rest der Datenbank bereits auf InnoDB lief. Seit MySQL 5.6 unterstützt auch InnoDB vollwertige FULLTEXT-Indizes, wodurch dieser Grund für MyISAM praktisch entfallen ist.

Moderne InnoDB-FULLTEXT-Indizes bieten dieselbe Grundfunktionalität wie ihre MyISAM-Pendants, inklusive Boolean-Mode-Suche und Relevanz-Ranking über MATCH ... AGAINST, kombiniert mit den Vorteilen von Transaktionen und Row-Level-Locking. Für neue Projekte gibt es damit keinen technischen Grund mehr, für Volltextsuche auf MyISAM zurückzugreifen, selbst wenn spezialisierte Suchlösungen wie Elasticsearch für komplexere Anforderungen weiterhin die bessere Wahl bleiben.

-- InnoDB fulltext index, no need to fall back to MyISAM anymore
CREATE TABLE articles (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    body TEXT NOT NULL,
    FULLTEXT KEY ft_title_body (title, body)
) ENGINE=InnoDB;

-- Boolean mode search with relevance ranking
SELECT id, title,
       MATCH(title, body) AGAINST('+mysql +performance' IN BOOLEAN MODE) AS relevance
FROM articles
WHERE MATCH(title, body) AGAINST('+mysql +performance' IN BOOLEAN MODE)
ORDER BY relevance DESC;

6. Storage-Overhead und Performance-Charakteristik

In reinen Lese-Benchmarks ohne Nebenläufigkeit war MyISAM historisch teilweise schneller als InnoDB, weil MyISAM weniger interne Buchführung betreiben muss und keine Undo-Logs für MVCC pflegt. Dieser Vorteil ist in modernen MySQL-Versionen weitgehend verschwunden, da InnoDB über Jahre stark optimiert wurde und der Buffer Pool effizienter arbeitet als der einfachere Key-Cache von MyISAM. Bei realistischen Workloads mit gemischten Lese- und Schreibzugriffen ist InnoDB inzwischen in fast allen Szenarien schneller.

Beim Speicherplatzbedarf unterscheiden sich die Engines ebenfalls: MyISAM speichert Daten- und Indexdatei getrennt und komprimiert Indizes standardmäßig, was bei reinen Lesetabellen einen geringeren Platzbedarf bedeuten kann. InnoDB benötigt durch die clustered Index-Struktur, bei der die Tabelle physisch nach dem Primärschlüssel sortiert ist, und durch zusätzliche Strukturen wie Undo-Logs tendenziell mehr Speicherplatz, gewinnt diesen Nachteil aber durch schnellere Primärschlüssel-Zugriffe wieder zurück, da keine separate Lookup-Operation nötig ist.

7. Wo MyISAM heute noch auftaucht

Trotz aller Nachteile begegnet man MyISAM in der Praxis noch an mehreren Stellen. Systemtabellen älterer MySQL-Versionen liefen historisch teilweise auf MyISAM, wobei moderne MySQL-8-Installationen dies weitgehend beseitigt haben. In Legacy-Anwendungen aus den 2000er- und frühen 2010er-Jahren, etwa alten Content-Management-Systemen oder selbstgebauten internen Tools, finden sich MyISAM-Tabellen häufig noch unverändert, weil eine Migration nie priorisiert wurde. Auch bei Datenimporten aus alten Backups oder bei der Migration von Fremdsystemen kann MyISAM unbemerkt in eine ansonsten moderne InnoDB-Datenbank gelangen.

Ein weiterer, oft übersehener Fall sind interne Statistik- oder Log-Tabellen, die bewusst auf MyISAM belassen wurden, weil Entwickler in der Vergangenheit annahmen, Transaktionssicherheit sei für unkritische Daten verzichtbar. Das kann in der Praxis problematisch werden, sobald diese Tabellen doch für geschäftskritische Auswertungen genutzt werden. Ein regelmäßiger Audit der eingesetzten Storage-Engines gehört deshalb zu jeder soliden Datenbank-Wartung.

-- Find every non-InnoDB table across all schemas, common audit query
SELECT
    table_schema,
    table_name,
    engine,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE engine IS NOT NULL
  AND engine != 'InnoDB'
  AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY size_mb DESC;

8. Migration von MyISAM zu InnoDB

Die Migration einer MyISAM-Tabelle zu InnoDB ist im einfachsten Fall ein einziger ALTER TABLE-Befehl, doch in der Praxis gibt es mehrere Fallstricke. Fehlt der Tabelle ein sinnvoller Primärschlüssel, was bei alten MyISAM-Tabellen keine Seltenheit ist, sollte vor der Migration einer ergänzt werden, da InnoDB als clustered Index intern immer einen Primärschlüssel benötigt und sonst einen versteckten erzeugt, der Zugriffe verlangsamt. Bei großen Tabellen kann ALTER TABLE ... ENGINE=InnoDB zudem erhebliche Zeit und temporären Speicherplatz benötigen, da die Tabelle intern komplett neu aufgebaut wird.

Für produktive Systeme mit wenig Wartungsfenster empfiehlt sich der Einsatz von Online-DDL-Tools wie pt-online-schema-change aus dem Percona Toolkit oder gh-ost, die die Migration ohne langwierige Tabellensperre durchführen. Vor jeder Migration sollte zudem geprüft werden, ob die Anwendung explizit LOCK TABLES-Syntax mit MyISAM-spezifischem Verhalten nutzt, da sich das Sperrverhalten nach der Migration grundlegend ändert.

-- Simple migration for small tables
ALTER TABLE legacy_reports ENGINE=InnoDB;

-- Verify the primary key exists before migrating large tables
SHOW KEYS FROM legacy_reports WHERE Key_name = 'PRIMARY';

-- For large production tables, prefer online schema change tools:
-- pt-online-schema-change --alter "ENGINE=InnoDB" \
--   D=shop_db,t=legacy_reports --execute

9. Feature-Matrix im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen InnoDB und MyISAM kompakt zusammen.

Für praktisch jeden modernen Anwendungsfall ist InnoDB die richtige Wahl. MyISAM bleibt nur in wenigen Nischen relevant, etwa bei rein lesenden, unkritischen Auswertungstabellen ohne jede Nebenläufigkeit, und selbst dort überwiegen mittlerweile die Vorteile einer einheitlichen Engine-Strategie.

10. Zusammenfassung

Der Vergleich InnoDB vs. MyISAM zeigt eindeutig, warum InnoDB seit über einem Jahrzehnt die Standardwahl ist: vollständige Transaktionsunterstützung, Row-Level-Locking für hohe Nebenläufigkeit und automatische Crash Recovery über das Redo Log machen InnoDB zur einzig sinnvollen Engine für praktisch jeden produktiven Anwendungsfall. MyISAM fehlt es an all diesen Eigenschaften, weshalb es in modernen Architekturen keine tragende Rolle mehr spielt.

Trotzdem lohnt sich das Wissen um die Unterschiede, weil MyISAM-Tabellen in Legacy-Systemen regelmäßig auftauchen, oft unbemerkt in einer ansonsten modernen InnoDB-Datenbank. Ein regelmäßiger Audit über information_schema.tables deckt solche Altlasten zuverlässig auf, und eine Migration mit Online-Schema-Change-Tools lässt sich auch in Produktionsumgebungen ohne größere Ausfallzeiten durchführen.

11. FAQ: InnoDB vs. MyISAM