APRENDER. PRATICAR. EVOLUIR.DML e DDL têm fronteiras diferentes
Começa por um controlo simples: numa transação InnoDB, insere uma nota, altera 100 para 90 e executa ROLLBACK. O laboratório voltou a observar 100 e nenhuma nota, mostrando a unidade de dados desfeita. O segundo percurso insere outra nota e executa CREATE TABLE antes do rollback. Desta vez, a nota ficou confirmada e a tabela continuou a existir. O comando de criação introduziu uma fronteira de commit que o rollback posterior não atravessa. Um script com START TRANSACTION no início não transforma todos os comandos seguintes numa unidade reversível. Lê cada instrução e identifica as fronteiras que realmente afetam a recuperação.
Falha do DDL não desfaz o commit anterior
No exemplo executado, ALTER TABLE tenta acrescentar uma coluna id que já existe e devolve 1060. A nota inserida antes desse comando continua visível para outra ligação depois de ROLLBACK. A falha de validação do schema não significa que o trabalho anterior tenha sido desfeito. Esta distinção é útil quando uma aplicação grava um marcador antes de iniciar uma migração: o marcador pode estar confirmado sem que a alteração pretendida tenha ocorrido. Não uses a presença desse registo como único critério de conclusão. Compara o schema observado, os dados afetados e o estado do mecanismo de migração antes de retomar a release.
Temporário não significa integralmente reversível
CREATE TEMPORARY TABLE não provocou commit da nota pendente no ensaio. Depois de inserir uma linha na tabela temporária e fazer rollback, a nota e a linha desapareceram, mas a tabela continuou presente na mesma sessão. DROP TEMPORARY TABLE também não confirmou a nota; contudo, o rollback não recriou a tabela removida. Se um processo depende desse objeto para a fase seguinte, precisa de uma limpeza ou reconstrução explícita. Separa a existência do objeto do conteúdo transacional que guarda. As duas propriedades podem ter resultados diferentes mesmo dentro do mesmo bloco de código e com o mesmo comando de rollback.
Operações diferentes sobre o mesmo objeto
A exceção observada para criação e remoção de tabelas temporárias não deve ser alargada a qualquer DDL sobre esses objetos. No laboratório, ALTER TABLE scratch acrescentou uma coluna à tabela temporária e confirmou a nota anterior. O rollback posterior deixou a nota confirmada e a coluna existente. Assim, a palavra temporária descreve o âmbito do objeto, mas não responde sozinha à pergunta sobre commits. Um inventário de migração deve indicar a instrução concreta, o tipo de objeto, a transação aberta e a verificação posterior. Testa o caminho de erro com o mesmo cuidado que o caminho em que todos os comandos terminam com sucesso.
TRUNCATE e savepoints numa release
TRUNCATE TABLE removeu as duas linhas sintéticas e confirmou a nota que o precedia. ROLLBACK não repôs os dados. Noutro percurso, um savepoint foi criado antes de ALTER TABLE acrescentar uma coluna; tentar regressar a esse savepoint devolveu 1305 e a coluna permaneceu. Estes resultados não são uma estratégia de recuperação de produção: apenas demonstram por que motivo rollback e savepoint não bastam para desfazer esses comandos. Antes de uma alteração destrutiva, o responsável pela release precisa de um caminho de recuperação apropriado ao serviço, com dados de teste e critérios de aceitação. O laboratório não restaurou backups nem ensaiou perda de dados real.
Tabela temporária e reutilização da sessão
Uma tabela temporária items com a linha 9 ocultou a tabela permanente do mesmo nome apenas na ligação que a criou. Outra ligação continuou a ler as linhas permanentes 1 e 2. Depois de DROP TEMPORARY TABLE, a primeira ligação voltou a ver a tabela permanente. Num fluxo com reutilização de ligações, esta propriedade exige cuidado com objetos residuais e nomes escolhidos pelos scripts. O ensaio usou ligações diretas e não validou um pool concreto. Documenta a necessidade de limpar ou reinicializar estado de sessão e verifica o comportamento real do mecanismo de reutilização antes de concluir que o pedido seguinte recebe um ambiente limpo.
START TRANSACTION;
INSERT INTO notes VALUES(3,'synthetic migration marker');
ALTER TABLE items ADD COLUMN id INT; -- Existing column: observed error 1060.
ROLLBACK;
-- On another owned connection, the earlier note remains committed.
SELECT * FROM notes WHERE id=3;Uma nota inserida antes de ALTER TABLE inválido ficou confirmada, apesar do erro 1060 e do ROLLBACK posterior.
Armadilhas comuns
Assumir DDL transacional; confiar num savepoint anterior; tratar todas as operações sobre tabelas temporárias como equivalentes.
Tópicos relacionados: Atomicidade e alterações de schema · Metadata locks e aceitação da release
O plano de recuperação deve acompanhar os commits efetivos e confirmar o estado do schema, dos dados e dos marcadores.
Referência: Implicit commit and temporary exceptions · MySQL 9.7 LTS with InnoDB reference semantics