Perché dovrei mai preferire ALGORITHM = COPY a ALGORITHM = INPLACE?

Da quando MySQL 5.6 ha introdotto DDL online, il ALTER TABLEcomando può facoltativamente avere uno ALGORITHM=INPLACEo ALGORITHM=COPYspecificato. La panoramica del DDL online osserva che, per impostazione predefinita, INPLACEviene utilizzato ovunque sia possibile e implica (senza mai affermarlo) che l' INPLACEalgoritmo è più economico di COPYquello che è.

Quindi quale motivo dovrei mai specificare ALGORITHM=COPYin una ALTER TABLEdichiarazione?

Sì, ci sono casi in cui è possibile specificare COPY, ma sarebbe per motivi diversi dalle prestazioni.

È importante capire che MySQL ha introdotto una nuova funzionalità: elaborazione DLL online nella versione 5.6. Non ha rimosso l'elaborazione offline. Quindi è necessario distinguere tra queste 2 modalità:

1. Alcune operazioni funzionano ancora solo in modalità offline. Vedere la Tabella 15.10, " Riepilogo dello stato online per le operazioni DDL " per un elenco delle operazioni DDL che possono o non possono essere eseguite sul posto.

2. Le operazioni in modalità online e offline hanno un comportamento leggermente diverso, quindi puoi sceglierne una "vecchia" per motivi di compatibilità.

Alcuni esempi (suggerisci di più):

1. Tabelle InnoDB creati prima di MySQL 5.6 non supportano ALTER TABLE ... ALGORITHM=INPLACEper le tabelle che includono colonne temporali ( DATE, DATETIMEo TIMESTAMP) e non sono stati ricostruiti utilizzando ALTER TABLE ... ALGORITHM=COPY. In questo caso, ALTER TABLE ... ALGORITHM=INPLACEun'operazione restituisce un errore.

2. ADD PRIMARY KEYla clausola in COPY modesilenzioso si converte NULLin valori predefiniti per quel tipo di dati (0 per INT, stringa vuota per varchar), mentre IN_PLACEnon lo fa.

Con la clausola ALGORITHM = COPY, l'operazione ha esito positivo nonostante la presenza di valori NULL nelle colonne della chiave primaria; i dati vengono modificati silenziosamente, il che potrebbe causare problemi.

Un altro motivo per preferire COPY:

Operazioni per le quali si specifica ALGORITHM = COPY o old_alter_table = 1, per forzare il comportamento di copia della tabella, se necessario, per una precisa compatibilità con le versioni precedenti in scenari specializzati.

Sebbene il manuale di MySQL non parli di scenari reali, puoi immaginarne alcuni. Ad esempio, lo sviluppatore ha fatto affidamento sul blocco della tabella durante il ALTER INDEXfunzionamento, pertanto la tabella è di sola lettura o completamente bloccata e esiste un processo che legge la tabella statica durante la ricostruzione dell'indice.

@Stoleg probabilmente ha la risposta migliore, ma eccone un'altra. È un'ipotesi plausibile che gli sviluppatori =COPYabbiano lasciato un trampolino di fuga nel caso in cui si fosse verificato un grave errore =INLINE. Ciò consentirebbe agli utenti di continuare a utilizzare ALTERanche se la nuova funzionalità è interrotta.

Ho visto cose del genere (in bandiere sql_mode, my.cnfimpostazioni, ecc.) Nel corso degli anni. L'intento della nuova versione è chiaramente quello di mettere in evidenza la nuova, migliore funzionalità.

I flag di ottimizzazione rientrano in questa categoria, ma ci sono ancora più motivi per aggrapparsi alle azioni precedenti: a volte l'ottimizzatore "farà sempre di sbagliato"; ci sono semplicemente troppe possibilità.

Nelle versioni di MySQL che supportano la crittografia del tablespace InnoDB, quando si modifica una tabella per aggiungere la crittografia, l'alterazione viene eseguita utilizzando l'algoritmo di copia per necessità.