Ich bin bereit, von MyISAM zu InnoDB zu wechseln, wollte aber wissen, ob es eine vollständige Liste der zu suchenden Dinge gibt? Ich habe zum Beispiel keine Liste erwähnt, in der erwähnt wird, dass das Ausführen DISABLE KEYSeiner InnoDB-Tabelle eine Warnung auslöst, mit Ausnahme der Handbuchseite für ALTER TABLE. So etwas muss ich wissen, bevor ich konvertiere. Ich dachte, ich würde meine Fragen gut beantworten, aber anscheinend nicht.

Hier sind einige Fallstricke

Speichernutzung

MyISAM

• speichert nur Indexseiten zwischen.
• gemeinsam genutzter Schlüsselcache (Größe nach key_buffer_size).
• Sie können auch einen dedizierten Schlüsselcache einrichten, eine oder mehrere Tabellen pro Cachetabelle .

InnoDB

• speichert Datenseiten und Indexseiten zwischen.
• ein Pufferpool und eine Größe vor MySQL 5.5
• 1 oder mehr Pufferpools ab MySQL 5.5

Hier sind einige Fragen, die ich zuvor geschrieben und gepostet habe, wie man eine geeignete Größe für den MyISAM-Schlüsselcache und den InnoDB-Pufferpool auswählt .

FULLTEXT-Indizes

MyISAM

• Unterstützt FULLTEXT-Indizes

InnoDB

• Beginnend mit MySQL 5.6, ja, aber noch in der Beta (UPDATE: MySQL 5.6 ist vorhanden und verfügt über FULLTEXT-Indizes. Wenn Sie die FULLTEXT-Indizierung in MySQL 5.6 verwenden, stellen Sie sicher, dass Sie die InnoDB-spezifischen FULLTEXT-Optionen verwenden. )
• Vor MySQL 5.6 bedeutet dies, dass Sie MyISAM nicht in InnoDB konvertieren können.

MySQL 5.5 und zurück

Führen Sie diese Abfrage aus, um festzustellen, welche MyISAM-Tabellen einen FULLTEXT-Index haben:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Was auch immer aus dieser Abfrage hervorgeht, kann erst nach einem Upgrade auf MySQL 5.6 in InnoDB konvertiert werden.

TABELLE OPTIMIEREN

MyISAM

• Die MyISAM-Tabelle ist verkleinert
• ANALYZE TABLE führt Indexstatistiken für alle Indizes aus

InnoDB

• ANALYZE TABLE ist völlig nutzlos, da Indexstatistiken immer wieder gespeichert werden
• Mit innodb_file_per_table deaktiviert wird ibdata1 größer werden
• Mit innodb_file_per_table aktiviert ist , ist Tabellen (.ibd) Datei geschrumpften

Ich denke, das größte Problem wäre, dass innodb transaktional ist. Sie möchten wissen, ob die MySQL-Bibliotheken, die von Ihren Anwendungen verwendet werden, standardmäßig auto_commit verwenden oder nicht.

Python schreibt beispielsweise nicht automatisch fest. Dies bedeutet, wenn eine Anwendung unmittelbar vor dem Schließen der Verbindung eine Zeile einfügt, wird diese Einfügung jetzt zurückgesetzt, nachdem Sie zu innodb geändert haben. Das Python-Skript muss beispielsweise sicher sein, connection.commit () aufzurufen.

Ein weiterer Unterschied könnte in mehrzeiligen Einfügungen oder Aktualisierungen liegen. Betrachten Sie einen einzelnen mehrzeiligen Inser

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Überlegen Sie, was passiert, wenn ein Fehler auftritt, z. B. eine eindeutige Schlüsselkollision in Zeile 3. Mit MyISAM wären die ersten beiden Zeilen geschrieben worden, unter innodb würden alle zu schreibenden Zeilen zurückgesetzt, so dass selbst bei einem solchen Fehler nichts geschrieben würde.

Mit innodb betreten Sie die Welt der Deadlocks. Diese sind nicht von Natur aus schlecht, es sei denn, sie treten mit einer solchen Häufigkeit auf, um zu verhindern, dass Arbeiten ausgeführt werden. Ihre Anwendungen müssen jedoch so codiert werden, dass sie Deadlocks antizipieren und angemessen behandeln (was höchstwahrscheinlich nur einen erneuten Versuch bedeutet).

Berücksichtigen Sie Speicher- / Speicherbeschränkungen. Innodb ist viel ressourcenintensiver als MyISAM. Wenn Sie über genügend RAM verfügen, um Ihre Pufferpools groß genug zu halten, um alle Ihre Tabellen aufzunehmen, sind Sie goldrichtig.

Suchen Sie nach Tabellen mit großen Primärschlüsseln. Die Clustered-Indizierung von Innodb bedeutet, dass jeder Sekundärindex eine weitere Kopie der PK der entsprechenden Zeile enthält. Wenn Sie 2 Sekundärindizes haben, bedeutet dies, dass jede Zeilen-PK dreimal gespeichert wird (PK + jeder Index). Wenn sich das pk über mehrere Spalten und große Datentypen erstreckt (z. B. char (N)), können Sie sehen, wie die Indexanforderungen unter innodb schnell explodieren können.