MySQL Storage Engine Vergleich – Warum MyISAM?

Neuerdings ist InnoDB die Standard-Engine von MySQL, was ich echt vernünftig finde. Ich finde es erstaunlich, wie sich MyISAM so lange halten konnte und würde gern verstehen, warum. Meiner Meinung nach zeichnet die Verbreitung von MyISAM ein trauriges Bild für Webanwendungen im Allgemeinen. Foreign Keys sind ein Segen! Deshalb die gewagte Aussage: Webanwendungen werden oft als wilder Hack hingeschustert, weswegen auch auf Datenbankseite keine vernünftige Integrität gebraucht wird.

Anders kann ich mir jedenfalls nicht erklären, wie es MyISAM zu solch einer hohen Verbreitung geschafft hat. Nachfolgend führe ich nochmal eine kleine (von mir kommentierte) Gegenüberstellung auf, die die wichtigsten Unterscheidungsmerkmale umfasst:

MyISAM

• Die Daten-Speicherung in little endian soll für eine Maschinenunabhängigkeit / Betriebssystemunabhängigkeit sorgen – Ich weiß nicht, in wiefern das im Webumfeld praxisrelevant ist (LAMP als Standard-Stack). Kommentare hierzu erwünscht!
• NULL-Werte sind in indizierten Spalten zulässig
• MyISAM unterstützt FULLTEXT-Indizes, Blobs und Text-Columns sind indizierbar – Praktisch!
• Die Höchstlänge für Schlüssel beträgt 1000 Bytes (kann aber durch ein rekompilieren beliebig angepasst werden)
• eine MyISAM-Tabelle kann maximal 64 Indizes haben – sollte reichen, wer mehr braucht hat oft beim Design was falsch gemacht.
• Pro Index dürfen es bis zu 16 Spalten sein
• Jede Tabelle wird getrennt gespeichert: Das Manual sagt dazu:
  

  Jede MyISAM-Tabelle wird in drei Dateien auf der Festplatte gespeichert. Die Namen der Dateien beginnen mit dem Tabellennamen und haben eine Erweiterung, die den Dateityp angibt. Eine .frm-Datei speichert das Tabellenformat. Die Datendatei besitzt die Erweiterung .MYD (MYData). Die Indexdatei hat die Erweiterung .MYI (MYIndex).

• Wohl das wichtigste Unterscheidungsmerkmal: MyISAM arbeitet mit Table-Locking. Das ist beim Lesen schneller als das Row-Locking von InnoDB, wird aber bei parallelen Reads/Writes die Schreibvorgänge verzögern. Siehe dazu: Erzeuger-Verbraucher-Problem.

InnoDB

• Man liest – verglichen mit MyISAM – oft von einer sichereren Recovery im Fall eines Crashes
• Referentielle Integrität durch Foreign-Key-Unterstützung. Für mich DAS Feature.
• Transaktionen. In ernstgemeinten, kritischen Anwendungen geht es nicht ohne.
• Das Manual sagt zur Serverauslastung:
  

  InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine.

Vielleicht habe ich ein Killer-Argument für MyISAM übersehen? Und was spricht eigentlich gegen eine gemischte Verwendung von MyISAM / InnoDB in der selben Datenbank je nach jeweiliger Anforderung an eine Tabelle?