Por que eu preferiria ALGORITHM = COPY a ALGORITHM = INPLACE?

Desde que o MySQL 5.6 introduziu o DDL online, o ALTER TABLEcomando pode ter opcionalmente ALGORITHM=INPLACEou ALGORITHM=COPYespecificado. A visão geral do DDL on-line observa que, por padrão, INPLACEé usada sempre que possível e implica (sem nunca afirmar isso) que o INPLACEalgoritmo é mais barato que o COPYoutro.

Então, qual motivo eu precisaria especificar ALGORITHM=COPYem uma ALTER TABLEdeclaração?

Sim, há casos em que você pode especificar COPY, mas seria por outros motivos que não o desempenho.

É importante entender que o MySQL introduziu um novo recurso - o processamento de DLL online na versão 5.6. Não removeu o processamento offline. Portanto, é necessário diferenciar entre esses dois modos:

1. Algumas operações ainda funcionam apenas no modo offline. Consulte a Tabela 15.10, “ Resumo do status on-line para operações DDL ” para obter uma lista das operações DDL que podem ou não ser executadas no local.

2. As operações nos modos Online e Offline têm um comportamento ligeiramente diferente, portanto você pode escolher o "antigo" por motivos de compatibilidade.

Alguns exemplos (sugira mais):

1. As tabelas InnoDB criadas antes do MySQL 5.6 não suportam ALTER TABLE ... ALGORITHM=INPLACEtabelas que incluem colunas temporais ( DATE, DATETIMEou TIMESTAMP) e não foram reconstruídas usando ALTER TABLE ... ALGORITHM=COPY. Nesse caso, uma ALTER TABLE ... ALGORITHM=INPLACEoperação retorna erro.

2. ADD PRIMARY KEYA cláusula in COPY modeconverte silenciosamente NULLem valores padrão para esse tipo de dados (0 para INT, sequência vazia para varchar), enquanto IN_PLACEque não faz isso.

Com a cláusula ALGORITHM = COPY, a operação é bem-sucedida, apesar da presença de valores NULL nas colunas da chave primária; os dados são alterados silenciosamente, o que pode causar problemas.

Outro motivo para preferir COPY:

Operações para as quais você especifica ALGORITHM = COPY ou old_alter_table = 1, para forçar o comportamento de cópia da tabela, se necessário, para uma compatibilidade com versões anteriores precisa em cenários especializados.

Embora o manual do MySQL não fale sobre cenários reais, você pode imaginar alguns. Por exemplo, o desenvolvedor contou com o bloqueio da tabela durante a ALTER INDEXoperação, para que a tabela seja somente leitura ou totalmente bloqueada e haja um processo que leia a tabela estática durante a reconstrução do índice.

@Stoleg provavelmente tem a melhor resposta, mas aqui está outra. É um palpite educado que os desenvolvedores deixaram =COPYcomo uma saída de emergência, caso houvesse um bug sério =INLINE. Isso permitiria que os usuários continuassem a usar, ALTERmesmo que o novo recurso estivesse quebrado.

Vi coisas assim (em sinalizadores sql_mode, my.cnfconfigurações etc.) ao longo dos anos. A intenção do novo lançamento é claramente trazer à tona o novo e melhor recurso.

Os sinalizadores de otimização se enquadram nessa categoria, mas há ainda mais motivos para se manter nas ações anteriores - o Otimizador sempre "faz errado" algumas vezes; existem simplesmente muitas possibilidades.

Nas versões do MySQL que oferecem suporte à criptografia de espaço de tabela InnoDB, quando você altera uma tabela para adicionar criptografia, a alteração é feita usando o algoritmo de cópia por necessidade.