APRENDER. PRATICAR. EVOLUIR.Uma leitura simples pode atrasar o schema
A ausência de FOR UPDATE não significa ausência de qualquer lock. Numa transação aberta, o SELECT simples usado no laboratório manteve um metadata lock sobre items. A outra ligação tentou alterar a estrutura e ficou pendente. Não houve necessidade de uma atualização de saldo para reproduzir a espera. O objetivo do lock é proteger o uso do objeto durante a transação, não reservar um valor de negócio como numa leitura com lock de linha. Para um incidente de release, identifica a transação aberta e a sua finalidade; tratar todas as esperas como conflito entre escritores pode esconder o verdadeiro titular que impede a alteração.
Observar metadata e identidade
O guião consultou performance_schema.metadata_locks e associou OWNER_THREAD_ID a performance_schema.threads para obter PROCESSLIST_ID. Confirmou um lock concedido com duração TRANSACTION na ligação titular e um pedido pendente na ligação do ALTER. Isto liga a observação aos clientes que o próprio ensaio criou. Não derives identificadores de ligação de campos que representam locks ou endereços internos. Numa ocorrência real, acrescenta responsável, finalidade e impacto da transação antes de intervir. O observador do laboratório era root local; portanto, a experiência não demonstra que uma conta operacional tenha esses privilégios nem valida o processo de autorização da equipa.
Timeout de metadata e trabalho já confirmado
A ligação do ALTER tinha lock_wait_timeout definido para um segundo e recebeu 1205 enquanto outra transação mantinha metadata. A coluna pretendida não foi acrescentada. Contudo, a nota inserida antes do ALTER ficou confirmada, porque esse comando tinha encerrado implicitamente a transação anterior. Esta observação combina duas fronteiras: espera pelo schema e commit do trabalho que o precedia. Não uses apenas o código 1205 para escolher uma política de recuperação, pois o mesmo número apareceu no laboratório de contenção InnoDB com outro comando e outro âmbito. Regista a instrução, a variável relevante e o estado confirmado antes de decidir repetir ou reconciliar.
LOCK=NONE e a janela de mudança
O segundo percurso acrescentou um índice com ALGORITHM=INPLACE e LOCK=NONE. Ainda assim, o pedido ficou pendente enquanto a leitura da outra transação mantinha metadata. Depois do rollback controlado dessa ligação, o índice foi criado. A opção não é uma promessa de latência zero, ausência de metadata locks ou custo desprezável. Este ensaio tem apenas duas linhas e não mede duração numa tabela de produção, impacto em I/O ou atraso de réplica. Usa o resultado para formular perguntas de aceitação: transações antigas foram identificadas, o prazo de espera foi definido e existe um responsável pela decisão se a mudança exceder a janela?
Falha de índice e significado de atomic DDL
As duas linhas tinham amount=100. Tentar acrescentar um índice UNIQUE nessa coluna devolveu 1062; as linhas originais permaneceram e o índice pretendido não existia. O resultado demonstra uma falha SQL controlada com estado observado depois da operação. A documentação descreve garantias de atomic DDL, mas isso não transforma DDL em comandos reversíveis pela transação do utilizador. Também não permite afirmar que este guião ensaiou crash recovery: o servidor não foi interrompido durante a alteração. Na revisão de release, mantém separadas a integridade da operação DDL, a confirmação de trabalho anterior e a recuperação perante falhas de infraestrutura que exigem testes próprios.
Definir aceitação com evidência delimitada
Um handover útil identifica o schema esperado, o resultado dos dados, os marcadores da migração e os testes dos consumidores. Os catorze grupos locais ajudam a construir esse raciocínio, mas não aprovam automaticamente uma framework de migração ou uma aplicação bancária. O ensaio usou um servidor nativo MySQL 9.7.2 descartável, três ligações próprias e dois comandos concorrentes, terminando os clientes e o servidor no fim. Não houve TCP, credenciais reais, pool, réplica, crash, benchmark ou oficina humana. Para o serviço concreto, ainda faltam uma janela representativa, critérios de rollback ou recuperação acordados, teste da aplicação e revisão do responsável técnico.
-- Connection A keeps a transaction open after a plain read.
START TRANSACTION;
SELECT * FROM items;
-- Connection B runs concurrently and may wait for metadata.
ALTER TABLE items ADD INDEX by_amount(amount), ALGORITHM=INPLACE, LOCK=NONE;
-- Connection A ends its transaction after the owned wait is observed.
ROLLBACK;Uma transação que só fez SELECT manteve um metadata lock. ALTER TABLE com LOCK=NONE esperou até essa transação terminar.
Armadilhas comuns
Interpretar LOCK=NONE como espera zero; usar só locks de linhas no diagnóstico; declarar crash recovery a partir de uma falha SQL controlada.
Tópicos relacionados: Atomicidade e alterações de schema · Metadata locks e aceitação da release
Uma release precisa de observar a espera, confirmar o resultado e provar o contrato da aplicação dentro do âmbito realmente ensaiado.
Referência: Transaction duration of metadata locks · MySQL 9.7 LTS with InnoDB reference semantics