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?
Mein Name ist
MyIsam hat nur so eine hohe Verbreitung, weil man es sich bei PMA so schön zusammen klicken kann/konnte und keiner was damit anfangen kann. Man kann da halt Volltext und Indizes und es liest auch recht fix – mehr brauchen die meisten nicht und es interessiert sie deshalb auch keinen. MyIsam ist jahrelang das „Schweizer Messer“ für niedrige bis mittlere Anforderungen gewesen. Wer mehr will oder mehr braucht, muss sich halt jede Tabellenengine anschauen und abwägen, was er denn gerne hätte. Jede hat halt ganz eigene Vor- und Nachteile. Wer es nicht braucht, bleibt halt bei dem, was reicht. So einfach ist das – so wie bei Windows. :-)
Gegen die gemischte Verwendung spricht gar nix. Du kannst ja z. B. auch einen Master mit InnoDB betreiben und die Replications mit MyIsam – weil das schneller liest oder Du den Fulltextindex haben willst. Ich hab auch schon Setups gehabt, wo sich nahezu nie ändernde Daten aus MyIsam Tabellen beim Starten in Memorytabellen kopiert wurden, um noch mal 2 % Leistung aus den JOINS raus zu holen.
Die OS Unabhängigkeit interessiert nach meiner Erfahrung auch keinen, weil die meisten eh über Backup/Restore gehen, ich hab einmal aus ner Notsituation heraus die Dateien kopiert, aber da war das OS auch gleich.
Also beim zusammenklicken kannste auch die Engine wechseln. Aber du wirst schon recht haben, dadurch dass es bei PMA der Default ist muss es ja wohl das Beste sein ;)
Die erste Todsünde beim Entwickeln: Ich weiß nicht, was es ist, also änder ich auch mal nix dran. :-)
Zur „Erklärung“ (keine Rechtfertigung): Bei den meisten Anwendungen ist es eh egal, ob MyIsam oder InnoDB, weil das Performanceargument in 99,98% aller Fälle überhaupt nicht greift, Transaktion aufgrund fehlender kritischer Daten uninteressant sind, Foreign Keys aufgrund fehlender Komplexität keine Rolle spielen und Crashs auch unter MyIsam meistens recovert werden können. Also warum sich damit beschäftigen wollen und wertvolle Zeit investieren?
Bei PHP seh ich das noch öfter, dass Funktionen aus dem Manual nicht genommen und dafür die wildesten Konstrukte geschrieben werden, weil der „Entwickler“ nicht in der Lage war, das Problem mal bei Mama Google einzugeben.
Natürlich kann man eine Zeile komplett aus der mysql lesen, in PHP eins dazu zählen, den alten Eintrag löschen und einen neuen rein schreiben, aber schön ist das nicht …
Haha, das waren jetzt fast meine Worte ;). Im Prinzip meinte ich ja genau das, mit „Webanwendungen werden oft als wilder Hack hingeschustert, weswegen auch auf Datenbankseite keine vernünftige Integrität gebraucht wird“.
Wobei das vielleicht zu abwertend klingt… Es gibt ja auch kleine, primitive Anwendungen die mit einer Tabelle auskommen oder bei denen Konsistenz kaum eine Rolle spielt. Size matters.
Das ist nicht abwertend – es ist ja legitim. Mir persönlich ist es auch latte, ob meine E-Mail in MyIsam oder InnoDB geschrieben wird.
Nur blöd wird es wenn irgendwann mal mehr Leute auf eine Seite kommen und plötzlich irgendwelche Flaschenhälse kommen und das Suchen im Dunkeln anfängt. Lustigerweise ist bisher auch jeder Datenbankserver, den ich kenne der mies auf MyIsam lief unter InnoDB die ersten paar Tage IMMER abgeschmiert.
Und richtig blöd wird es, wenn bei der Sicherheit genau so gewurstet wurde wie bei der Skalierbarkeit. Und das ist leider ganz oft der Fall. :-/
Zumeist wird MySQL zur simplene Ablage von Daten genutzt. Die Relationen zwischen Tabellen werden später im Code modelliert. Dafür ist MyISAM ausreichend. Das Foreign Keys einige Features mitrbingen, die die Arbeit erleichtern wird ignoriert oder ist gar nicht bekannt. Hier muss ich auch zustimmen, dass im PMA foreign keys nicht so einfach zusammengeklickt werden können, wie die Tabellenspalten.
Ich denke, dass Unwissenheit die Verbreitung gefördert hat. Und für weitreichende Refactorings hat dann heute niemand Lust.