APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
DDL não partilha automaticamente as garantias de rollback esperadas de DML. ALTER TABLE causa implicit commit; executar UPDATE e ALTER na mesma sessão não cria uma única unidade reversível por ROLLBACK. Atomic DDL protege a consistência de operações suportadas, sem transformar DDL em transações controladas livremente pelo utilizador. Existem exceções específicas, como CREATE TEMPORARY TABLE sem implicit commit, cuja criação também não é desfeita por rollback. O algoritmo de alteração define trabalho físico e concorrência possível. INSTANT, INPLACE e COPY têm capacidades distintas, dependentes da operação e estrutura da tabela.
Aplicação guiada
Num rollout fictício, remover uma coluna rapidamente pode quebrar instâncias antigas ainda ativas. Introduz compatibilidade, migra utilização e dados, confirma consumidores e só depois retira a estrutura antiga. Se INSTANT for rejeitado, reavalia tempo, espaço e locks antes de aceitar outro algoritmo. Online DDL também precisa de metadata locks: uma transação antiga que apenas leu a tabela pode atrasar a mudança. Define prazo máximo, owner da transação e critério de adiamento. A aceitação deve verificar schema, aplicação, impacto no batch e caminho de retorno. Backup e mudança inversa não significam que o rollback seja imediato ou sem reconciliação.
Uma transação após SELECT pode reter metadata lock e bloquear ALTER TABLE até terminar.
Armadilhas comuns
Atomic como rollback livre; INSTANT como compatível; online como sem locks; remover algoritmo sem medir impacto.
Tópicos relacionados: Tipos e contratos dos dados · Consultas determinísticas e planos · Transações InnoDB e caminhos de erro
A release precisa de compatibilidade funcional e de uma janela operacional demonstrada.
Referência: DDL and implicit commits · MySQL 9.7 LTS with InnoDB reference semantics