Wie wählt man eine MySQL-Datenbank-Engine?

Wie wählen Sie insbesondere zwischen MyISAM und InnoDB aus, wenn keines der beiden Features fehlt (z. B. Sie benötigen keine Fremdschlüssel).

Kommt es immer darauf an, beides zu versuchen und zu messen? Oder gibt es gute Faustregeln in Bezug auf die Anzahl und Häufigkeit der Lese- und Schreibvorgänge und ähnlicher Maßnahmen? Hat die Größe der Tabelle einen Einfluss auf die typische Auswahl?

Die Antwort ist, dass Sie immer messen sollten, vorzugsweise mit Ihren eigenen Daten und Ihrer Arbeitsbelastung, wenn dies möglich ist.

Da die Datenzugriffsmuster von App zu App sehr unterschiedlich sein können, ist es schwer zu sagen und höchstwahrscheinlich unmöglich, eine "beste" Speicher-Engine für alle Workloads zu ermitteln.

Es gibt jedoch sehr vielversprechende Entwicklungen im MySQL-Bereich, nachdem sie letzte Woche an der MySQLConf / Percona Performance Conf teilgenommen haben.

Einige der alternativen Speicher-Engines:

1. XtraDB (Fork von InnoDB)
2. InnoDB-Plugin
3. PBXT
4. TokuDB

Außerdem haben Percona, Google usw. Patches beigesteuert, die die Leistung von InnoDB erheblich verbessern. Persönlich führe ich einen OurDelta-Build aus. Es funktioniert gut für mich und ich empfehle, die Builds OurDelta und Percona auszuprobieren.

Wenn es sich nur um ein einfaches Filial- / Berichtssystem handelt, verwende ich MyISAM für seine Rohleistung.

Ich würde InnoDB verwenden, wenn ich über mehrere gleichzeitige Zugriffe mit vielen Schreibvorgängen besorgt wäre, um das Sperren auf Zeilenebene zu nutzen.

Es gibt eine Reihe von Benchmarks für verschiedene MySQL-Datenbank-Engines. Es gibt einen anständigen Vergleich zwischen MyISAM, InnoDB und Falcon im Percona MySQL Performance Blog , siehe hier .

Eine andere Sache, die zwischen den beiden oben genannten Engines (MyISAM und InnoDB) beachtet werden muss, ist ihre Vorgehensweise beim Sperren. MyISAM führt eine Tabellensperre durch, während InnoDB eine Zeilensperre durchführt. Es gibt eine Vielzahl von Faktoren zu berücksichtigen, nicht nur die tatsächlichen Leistungsdaten.

Es gibt Funktionen, die Sie aus betrieblichen Gründen sehr nützlich finden, auch wenn Ihre Anwendung sie nicht unbedingt benötigt:

• InnoDB hat MVCC, was bedeutet, dass Sie nicht blockierende konsistente Backups erstellen können
• InnoDB verfügt über eine automatische Wiederherstellung, was bedeutet, dass nach einem unsauberen Herunterfahren keine langwierigen REPAIR TABLE-Vorgänge erforderlich sind
• Mit InnoDB blockieren Leser niemals Schreiber und umgekehrt, was (im Allgemeinen) eine größere Parallelität bedeutet (dies muss jedoch im Allgemeinen keine bessere Leistung bedeuten).
• InnoDB gruppiert seine Zeilen auf dem Primärschlüssel, was möglicherweise weniger E / A-Operationen für Leseoperationen bedeutet, wenn der Primärschlüssel ausreichend gut ausgewählt wurde.

Ungeachtet der Einschränkungen durch Fremdschlüssel möchten Sie InnoDB wahrscheinlich trotzdem verwenden.

Das ist natürlich ServerFault, nicht Stack Overflow. Die richtige Antwort lautet also:

• Sie müssen immer die Engine verwenden, die die Anwendungsentwickler ausgewählt haben
• Wenn sie sich nicht für eine bestimmte Engine entschieden haben, nehmen sie die Verwendung von MySQL nicht sehr ernst und wissen wahrscheinlich nicht, wie sie richtig damit umgehen sollen.
• Sie können nicht auf eine andere Engine als die wechseln, auf der Ihre Anwendung getestet wurde, da dies zu Fehlern führen kann.

Mein Hosting-Provider hat uns geraten, MyISAM komplett zu entfernen und auf InnoDB zu wechseln, sofern dies nicht möglich ist.

In unserem Fall hatten wir eine schwere Datenbeschädigung, die einige Male bis einige Male pro Tag auftrat und immer REPAIR TABLE und zugehörige Befehle erforderte, was bei großen Tabellen einige Zeit in Anspruch nahm.

Sobald wir zu InnoDB konvertiert (oder konvertiert wurden), verschwanden die Probleme sofort. Nachteile / Vorbehalte, die wir hatten:

• Kann Tabellen mit FULLTEXT-Index nicht konvertieren (dieses Problem hat sich im Laufe der Zeit von selbst gelöst; es wurde durch eine Solr / Lucene-basierte Lösung ersetzt, die ohnehin eine viel bessere Qualität aufweist)
• Große Tabellen mit Millionen von Zeilen, die oft COUNT (*) erfordern, waren sehr langsam, wir konnten diese auch nicht wechseln.

Beachten Sie jedoch, dass dies alles nur für unsere Umgebung usw. gilt und daher möglicherweise nicht generell gilt.