it-swarm.com.de

Warum sollte ich ALGORITHM = COPY ALGORITHM = INPLACE vorziehen?

Seit MySQL 5.6 Online-DDL eingeführt hat, kann für den Befehl ALTER TABLE optional entweder ALGORITHM=INPLACE Oder ALGORITHM=COPY Angegeben werden. Das Übersicht über Online-DDL stellt fest, dass standardmäßig INPLACE verwendet wird, wo immer dies möglich ist, und impliziert ( ohne es jemals ganz zu sagen), dass der INPLACE Algorithmus billiger ist als der COPY.

Welchen Grund hätte ich jemals, ALGORITHM=COPY In einer ALTER TABLE - Anweisung anzugeben?

19
Mark Amery

Ja, es gibt Fälle, in denen Sie COPY angeben können, dies jedoch aus anderen Gründen als der Leistung.

Es ist wichtig zu verstehen, dass MySQL eine neue Funktion eingeführt hat - Online DLL-Verarbeitung in Version 5.6. Die Offline-Verarbeitung wurde nicht entfernt. Daher muss zwischen diesen beiden Modi unterschieden werden:

  1. Einige Vorgänge funktionieren nur im Offline-Modus. In Tabelle 15.10, „ Zusammenfassung des Online-Status für DDL-Vorgänge “ finden Sie eine Liste der DDL-Vorgänge, die direkt ausgeführt werden können oder nicht.

  2. Vorgänge im Online- und Offline-Modus weisen ein geringfügig unterschiedliches Verhalten auf, sodass Sie aus Kompatibilitätsgründen den "alten" auswählen können.

Einige Beispiele (bitte schlagen Sie mehr vor):

  1. InnoDB-Tabellen, die vor MySQL 5.6 erstellt wurden, unterstützen ALTER TABLE ... ALGORITHM=INPLACE nicht für Tabellen, die zeitliche Spalten (DATE, DATETIME oder TIMESTAMP) enthalten und nicht mit neu erstellt wurden ALTER TABLE ... ALGORITHM=COPY. In diesem Fall gibt eine Operation ALTER TABLE ... ALGORITHM=INPLACE einen Fehler zurück.

  2. ADD PRIMARY KEY Klausel in COPY mode konvertiert NULL stillschweigend in Standardwerte für diesen Datentyp (0 für INT, leere Zeichenfolge für varchar), während IN_PLACE macht das nicht.

Mit der ALGORITHM = COPY-Klausel ist die Operation trotz des Vorhandenseins von NULL-Werten in den Primärschlüsselspalten erfolgreich. Die Daten werden stillschweigend geändert, was zu Problemen führen kann.

Ein weiterer Grund, COPY zu bevorzugen:

Vorgänge, für die Sie ALGORITHM = COPY oder old_alter_table = 1 angeben, um das Verhalten beim Kopieren von Tabellen zu erzwingen, falls dies für eine präzise Abwärtskompatibilität in speziellen Szenarien erforderlich ist.

Obwohl das MySQL-Handbuch nicht über tatsächliche Szenarien spricht, können Sie sich einige vorstellen. Z.B. Der Entwickler hat sich darauf verlassen, dass die Tabelle während des Vorgangs ALTER INDEX gesperrt ist, sodass die Tabelle schreibgeschützt oder vollständig gesperrt ist und es einen Prozess gibt, der die statische Tabelle während der Indexwiederherstellung liest.

13
Stoleg

@Stoleg hat wahrscheinlich die beste Antwort, aber hier ist eine andere. Es ist eine fundierte Vermutung, dass die Entwickler =COPY als Notluke für den Fall, dass ein schwerwiegender Fehler in =INLINE. Auf diese Weise können Benutzer ALTER weiterhin verwenden, auch wenn die neue Funktion nicht verfügbar ist.

Ich habe solche Dinge gesehen (in Flaggen, sql_mode, my.cnf Einstellungen usw.) im Laufe der Jahre. Die Absicht der neuen Version ist eindeutig, die neue, bessere Funktion herauszubringen.

Optimierungsflags fallen in diese Kategorie, aber es gibt noch mehr Gründe, an den vorherigen Aktionen festzuhalten - der Optimierer macht es manchmal immer "falsch"; Es gibt einfach zu viele Möglichkeiten.

2
Rick James