Eines meiner Projekte verwendet die MyISAM-Engine in MySQL, aber ich überlege, auf InnoDB umzusteigen, da ich hier und da Transaktionsunterstützung benötige.
Ja, auf jeden Fall, es gibt viele Dinge, da sollte man seine Anwendung sehr gründlich testen:
Der Migrationsprozess selbst muss sorgfältig geplant werden, da er bei großen Datenmengen sehr lange dauern kann (während dieser Zeit sind die Daten entweder schreibgeschützt oder gar nicht verfügbar - prüfen Sie das!)
Es gibt jedoch einen großen Vorbehalt. Wenn während eines Schreibvorgangs ein Hardwarefehler (oder ähnliches) auftritt, wird InnoDB die Tabellen beschädigen.
MyISAM tut das auch, aber ein mysqlcheck --auto-repair wird sie reparieren. Der Versuch, dies mit InnoDB-Tabellen zu tun, wird fehlschlagen. Ja, das ist aus Erfahrung.
Das bedeutet, dass Sie einen guten Plan zur regelmäßigen Datensicherung haben müssen, um InnoDB zu verwenden.
Einige andere Anmerkungen:
InnoDB weist keinen freien Speicherplatz auf dem Dateisystem zu, nachdem Sie eine Tabelle/Datenbank löschen oder einen Datensatz löschen. Dies kann durch "Dumping und Importieren" oder durch Setzen von innodb_file_per_table=1 in my.cnf.
Das Hinzufügen/Entfernen von Indizes in einer großen InnoDB-Tabelle kann ziemlich mühsam sein, da die aktuelle Tabelle gesperrt wird, eine temporäre Tabelle mit den geänderten Indizes erstellt wird und Daten Zeile für Zeile eingefügt werden. Es gibt eine Plugin von Innobase aber es funktioniert nur für MySQL 5.1
InnoDB ist auch VIEL speicherintensiver, ich empfehle Ihnen, so große innodb_buffer_pool_size so variabel, wie es der Arbeitsspeicher Ihres Servers zulässt (70-80 % sollten ein sicherer Wert sein). Wenn Ihr Server UNIX/Linux ist, sollten Sie die sysctl-Variable vm.swappiness auf 0 und verwenden innodb_flush_method=O_DIRECT um doppelte Pufferung zu vermeiden. Testen Sie immer, ob Sie beim Umschalten dieser Werte auf Swap stoßen, und lesen Sie mehr unter Percona-Blog was großartig ist.
Außerdem können Sie mysqlbackup con --single-transaction --skip-lock-tables und keine Tabellensperren haben, während die Sicherung beginnt.
Auf jeden Fall ist InnoDB großartig, lassen Sie sich nicht von einigen Fallstricken entmutigen.
Eine Änderung der Tabelle und die Einstellung des Motors sollten genügen.
Einer der wichtigsten Punkte, auf den Sie achten sollten, ist, dass select count(*) from MyTable es viel langsamer in InnoDB als MyISAM.
auto_increment Werte werden nach einem Server-Neustart auf den höchsten Wert in der Tabelle +1 zurückgesetzt -- dies kann zu lustigen Problemen führen, wenn Sie eine unordentliche Datenbank mit einigen Löschungen haben.
Die optimalen Servereinstellungen werden sich von denen einer MyISAM-Datenbank unterscheiden.
Vergewissern Sie sich, dass die Größe der innodb-Datei groß genug ist, um alle Ihre Daten zu speichern, sonst werden Sie durch ständige Neuzuweisungen gekreuzigt, wenn Sie die Motoren der Tabellen ändern.
Wenn Sie beabsichtigen, InnoDB als Möglichkeit für gleichzeitige Abfragen zu verwenden, dann müssen Sie innodb_file_trx_commit=1 damit Sie etwas Leistung zurückbekommen. OTOH, wenn Sie Ihre Anwendung neu programmieren möchten, um transaktionsbewusst zu sein, dann wird die Entscheidung über diese Einstellung Teil der allgemeinen Leistungsüberprüfung sein, die für die InnoDB-Einstellungen erforderlich ist.
Der andere wichtige Punkt, auf den Sie achten müssen, ist, dass InnoDB weder FullText-Indizes noch INSERT DELAYED unterstützt. Aber MyISAM unterstützt ja auch keine referentielle Integrität :-)
Sie können jedoch nur die Tabellen verschieben, die Sie für eine Transaktion benötigen. Ich habe das getan. Kleine Tabellen (bis zu mehreren Tausend Zeilen) können übrigens oft on-the-fly geändert werden.
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.
