892 Stimmen

MyISAM gegenüber InnoDB

Ich arbeite an einem Projekt, bei dem viel in Datenbanken geschrieben wird, würde ich sagen ( 70% Beilagen und 30% Lesestoff ). Dieses Verhältnis würde auch Aktualisierungen einschließen, die ich als ein Lesen und ein Schreiben betrachte. Die Lesevorgänge können unsauber sein (z. B. benötige ich keine 100%ig genauen Informationen zum Zeitpunkt des Lesens).
Die betreffende Aufgabe wird über 1 Million Datenbanktransaktionen pro Stunde umfassen.

Ich habe eine Reihe von Sachen auf dem Web über die Unterschiede zwischen MyISAM und InnoDB gelesen, und MyISAM scheint wie die offensichtliche Wahl zu mir für die bestimmte Datenbank/Tabellen, die ich für diese Aufgabe verwenden werden. Nach dem, was ich zu lesen scheine, ist InnoDB gut, wenn Transaktionen benötigt werden, da Sperren auf Zeilenebene unterstützt wird.

Hat jemand Erfahrung mit dieser Art von Belastung (oder höher)? Ist MyISAM der richtige Weg?

14 Stimmen

Le MySQL-Leistungs-Blog ist eine großartige Quelle für diese Art von Dingen.

3 Stimmen

Dies hängt ein wenig davon ab, ob Ihr System OLTP- oder eher Datawarehouse-orientiert ist (wo die meisten Schreibvorgänge in großen Mengen erfolgen).

38 Stimmen

MyISAM unterstützt kein Row-Locking, keine Transaktionen, es unterstützt nicht einmal Fremdschlüssel... verdammt, da es keine SÄURE kann man kaum noch von einer richtigen Datenbank sprechen! Das ist der Grund, warum InnoDB seit MySQL 5.5 die Standard-Engine ist... aber, aus welchem Grund auch immer, ist MyISAM weiterhin die Standard-Engine für Tabellen, die mit PhpMyAdmin erstellt werden, so dass viele Amateur-Datenbanken seitdem auf MyISAM laufen.

539voto

developer99 Punkte 5389

Ich habe kurz diskutiert diese Frage in einer Tabelle, damit Sie entscheiden können, ob Sie sich für InnoDB ou MyISAM .

Hier ist ein kleiner Überblick darüber, welche DB-Speicher-Engine Sie in welcher Situation verwenden sollten:

                                                 MyISAM   InnoDB
----------------------------------------------------------------
Required full-text search                        Yes      5.6.4
----------------------------------------------------------------
Require transactions                                      Yes
----------------------------------------------------------------
Frequent select queries                          Yes      
----------------------------------------------------------------
Frequent insert, update, delete                           Yes
----------------------------------------------------------------
Row locking (multi processing on single table)            Yes
----------------------------------------------------------------
Relational base design                                    Yes

Zusammenfassung

  • In fast allen Fällen, InnoDB ist der beste Weg zu gehen
  • Aber, häufiges Lesen, fast kein Schreiben, Verwendung MyISAM
  • Volltextsuche in MySQL <= 5.5, verwenden Sie MyISAM

271voto

rix0rrr Punkte 9278

Ich bin kein Datenbankexperte und spreche auch nicht aus Erfahrung. Wie auch immer:

MyISAM-Tabellen verwenden Sperren auf Tabellenebene . Ausgehend von Ihren Verkehrsschätzungen haben Sie fast 200 Schreibvorgänge pro Sekunde. Mit MyISAM, Es kann immer nur eine der beiden Aktionen in Gang sein. . Sie müssen sicherstellen, dass Ihre Hardware mit diesen Transaktionen Schritt halten kann, um eine Überlastung zu vermeiden, d. h. eine einzelne Abfrage darf nicht länger als 5 ms dauern.

Das legt mir nahe, dass Sie eine Speichermaschine benötigen, die Sperren auf Zeilenebene unterstützt, d. h. InnoDB.

Andererseits dürfte es recht trivial sein, ein paar einfache Skripte zu schreiben, um die Last mit jeder Speicher-Engine zu simulieren und dann die Ergebnisse zu vergleichen.

201voto

Bill Karwin Punkte 493880

Es wird oft über Leistung, Lese- und Schreibvorgänge, Fremdschlüssel usw. gesprochen, aber meiner Meinung nach gibt es noch eine weitere Funktion, die bei einer Speicher-Engine nicht fehlen darf: atomare Aktualisierungen.

Versuchen Sie dies:

  1. Geben Sie ein UPDATE für Ihre MyISAM-Tabelle aus, das 5 Sekunden dauert.
  2. Während der UPDATE läuft, etwa nach 2,5 Sekunden, drücken Sie Strg-C, um ihn zu unterbrechen.
  3. Beobachten Sie die Auswirkungen auf den Tisch. Wie viele Zeilen wurden aktualisiert? Wie viele wurden nicht aktualisiert? Ist die Tabelle überhaupt lesbar, oder wurde sie beschädigt, als Sie Strg-C gedrückt haben?
  4. Versuchen Sie das gleiche Experiment mit UPDATE gegen eine InnoDB-Tabelle, wobei Sie die laufende Abfrage unterbrechen.
  5. Beobachten Sie die InnoDB-Tabelle. Null Zeilen wurden aktualisiert. InnoDB hat sichergestellt, dass Sie atomare Aktualisierungen haben, und wenn die vollständige Aktualisierung nicht bestätigt werden konnte, wird die gesamte Änderung zurückgesetzt. Außerdem ist die Tabelle nicht beschädigt. Dies funktioniert auch, wenn Sie killall -9 mysqld um einen Absturz zu simulieren.

Leistung ist natürlich wünschenswert, aber keine Daten zu verlieren sollte das übertrumpfen.

138voto

alanc10n Punkte 4609

Ich habe an einem hochvolumigen System gearbeitet, das MySQL verwendet, und ich habe sowohl MyISAM als auch InnoDB ausprobiert.

Ich habe festgestellt, dass die Sperrung auf Tabellenebene in MyISAM ernsthafte Leistungsprobleme für unsere Arbeitslast verursacht, die ähnlich wie Ihre klingt. Leider musste ich auch feststellen, dass die Leistung unter InnoDB ebenfalls schlechter war als erhofft.

Schließlich löste ich das Problem, indem ich die Daten so fragmentierte, dass Einfügevorgänge in eine "heiße" Tabelle gingen und Auswahlvorgänge nie die heiße Tabelle abfragten.

Dies ermöglichte auch Löschungen (die Daten waren zeitkritisch und wir behielten nur die Daten von X Tagen) in "veralteten" Tabellen, die wiederum nicht von Select-Abfragen berührt wurden. InnoDB scheint eine schlechte Leistung bei Massenlöschungen zu haben. Wenn Sie also vorhaben, Daten zu löschen, sollten Sie sie so strukturieren, dass die alten Daten in einer "alten" Tabelle liegen, die einfach gelöscht werden kann, anstatt sie zu löschen.

Natürlich habe ich keine Ahnung, was Ihre Anwendung ist, aber hoffentlich gibt Ihnen dies einen Einblick in einige der Probleme mit MyISAM und InnoDB.

68voto

d4nyll Punkte 10512

Ein bisschen spät dran... aber hier ist eine recht umfassende Beitrag, den ich vor ein paar Monaten geschrieben habe in dem die wichtigsten Unterschiede zwischen MYISAM und InnoDB erläutert werden. Nehmen Sie sich eine Tasse Tee (und vielleicht einen Keks) und genießen Sie.


Der Hauptunterschied zwischen MyISAM und InnoDB liegt in der referenziellen Integrität und den Transaktionen. Darüber hinaus gibt es weitere Unterschiede wie Sperren, Rollbacks und Volltextsuche.

Referentielle Integrität

Die referentielle Integrität stellt sicher, dass die Beziehungen zwischen den Tabellen konsistent bleiben. Konkret bedeutet dies, dass, wenn eine Tabelle (z. B. Listings) einen Fremdschlüssel (z. B. Product ID) hat, der auf eine andere Tabelle (z. B. Products) verweist, bei Aktualisierungen oder Löschungen in der Tabelle, auf die verwiesen wird, diese Änderungen kaskadenartig auf die verknüpfende Tabelle übertragen werden. Wenn in unserem Beispiel ein Produkt umbenannt wird, werden die Fremdschlüssel der verknüpfenden Tabelle ebenfalls aktualisiert; wenn ein Produkt aus der Tabelle "Produkte" gelöscht wird, werden alle Einträge, die auf den gelöschten Eintrag verweisen, ebenfalls gelöscht. Außerdem muss jeder neue Eintrag einen Fremdschlüssel haben, der auf einen gültigen, bestehenden Eintrag verweist.

InnoDB ist ein relationales DBMS (RDBMS) und verfügt daher über referentielle Integrität, während MyISAM dies nicht tut.

Transaktionen und Atomarität

Die Daten in einer Tabelle werden mit Data Manipulation Language (DML)-Anweisungen wie SELECT, INSERT, UPDATE und DELETE verwaltet. Eine Transaktion fasst zwei oder mehr DML-Anweisungen zu einer einzigen Arbeitseinheit zusammen, so dass entweder die gesamte Einheit angewendet wird oder nichts davon.

MyISAM unterstützt keine Transaktionen, InnoDB hingegen schon.

Wenn ein Vorgang unterbrochen wird, während eine MyISAM-Tabelle verwendet wird, wird der Vorgang sofort abgebrochen, und die betroffenen Zeilen (oder sogar die Daten in jeder Zeile) bleiben betroffen, auch wenn der Vorgang nicht zu Ende geführt wurde.

Wenn eine Operation unterbrochen wird, während eine InnoDB-Tabelle verwendet wird, weil sie Transaktionen verwendet, die atomisiert sind, wird jede Transaktion, die nicht abgeschlossen wurde, nicht wirksam, da keine Übergabe erfolgt.

Tabellenverriegelung vs. Zeilenverriegelung

Wenn eine Abfrage gegen eine MyISAM-Tabelle läuft, wird die gesamte Tabelle, in der sie abgefragt wird, gesperrt. Das bedeutet, dass nachfolgende Abfragen erst dann ausgeführt werden, wenn die aktuelle Abfrage beendet ist. Wenn Sie eine große Tabelle lesen und/oder es häufige Lese- und Schreibvorgänge gibt, kann dies einen großen Rückstau an Abfragen bedeuten.

Wenn eine Abfrage auf eine InnoDB-Tabelle läuft, werden nur die betroffenen Zeilen gesperrt, der Rest der Tabelle bleibt für CRUD-Operationen verfügbar. Das bedeutet, dass Abfragen gleichzeitig auf derselben Tabelle ausgeführt werden können, sofern sie nicht dieselbe Zeile verwenden.

Diese Funktion in InnoDB wird als Gleichzeitigkeit bezeichnet. So großartig die Gleichzeitigkeit auch ist, es gibt einen großen Nachteil, der für eine Reihe ausgewählter Tabellen gilt: Es gibt einen Overhead beim Umschalten zwischen Kernel-Threads, und Sie sollten ein Limit für die Kernel-Threads festlegen, um zu verhindern, dass der Server zum Stillstand kommt.

Transaktionen und Rollbacks

Wenn Sie eine Operation in MyISAM ausführen, werden die Änderungen übernommen; in InnoDB können diese Änderungen rückgängig gemacht werden. Die gängigsten Befehle zur Steuerung von Transaktionen sind COMMIT, ROLLBACK und SAVEPOINT. 1. COMMIT - Sie können mehrere DML-Operationen schreiben, aber die Änderungen werden nur gespeichert, wenn ein COMMIT ausgeführt wird 2. ROLLBACK - Sie können alle Operationen verwerfen, die noch nicht übertragen wurden 3. SAVEPOINT - legt einen Punkt in der Liste der Operationen fest, zu dem eine ROLLBACK-Operation zurückgehen kann

Verlässlichkeit

MyISAM bietet keine Datenintegrität - Hardwareausfälle, unsauberes Herunterfahren und abgebrochene Operationen können dazu führen, dass die Daten beschädigt werden. Dies würde eine vollständige Reparatur oder einen Neuaufbau der Indizes und Tabellen erfordern.

InnoDB hingegen verwendet ein Transaktionsprotokoll, einen doppelten Schreibpuffer und eine automatische Prüfsummenbildung und Validierung, um Korruption zu verhindern. Bevor InnoDB Änderungen vornimmt, zeichnet es die Daten vor den Transaktionen in einer System-Tablespace-Datei namens ibdata1 auf. Im Falle eines Absturzes würde InnoDB durch die Wiedergabe dieser Protokolle eine automatische Wiederherstellung vornehmen.

FULLTEXT-Indizierung

InnoDB unterstützt die FULLTEXT-Indizierung erst ab MySQL-Version 5.6.4. Zum Zeitpunkt der Erstellung dieses Beitrags liegt die MySQL-Version vieler Shared-Hosting-Anbieter noch unter 5.6.4, was bedeutet, dass FULLTEXT-Indexierung für InnoDB-Tabellen nicht unterstützt wird.

Dies ist jedoch kein triftiger Grund, MyISAM zu verwenden. Wechseln Sie am besten zu einem Hosting-Anbieter, der aktuelle Versionen von MySQL unterstützt. Eine MyISAM-Tabelle, die FULLTEXT-Indizierung verwendet, kann nicht in eine InnoDB-Tabelle konvertiert werden.

Schlussfolgerung

Zusammenfassend lässt sich sagen, dass InnoDB die Standard-Speicher-Engine Ihrer Wahl sein sollte. Entscheiden Sie sich für MyISAM oder andere Datentypen, wenn sie einen bestimmten Bedarf erfüllen.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X