Eu tenho uma pergunta sobre a ALTER TABLE ... ADD COLUMNinstrução DDL .
Em uma instância do Amazon RDS com MariaDB v10.2, notei que INSERTas instruções são concluídas e as linhas são inseridas corretamente na tabela (conforme verificado via SELECT) antes que um ALTER TABLE ... ADD COLUMNna tabela seja concluído.
Nenhuma instrução DML que executa uma gravação deve ser enfileirada até que a ALTER TABLEoperação termine?
Estou postando esta pergunta porque me pediram para realizar alguns testes para verificar se é possível executar ALTER TABLE ... ADD COLUMNem um banco de dados de produção ativo em horário comercial, em um banco de dados muito usado, em tabelas com vários milhões de linhas - o que eu achar muito desaconselhável. Mesmo que ALTER TABLEnão coloque um bloqueio na tabela, terá que esperar até que alguma conexão não esteja mais usando a tabela (devido à conexão colocar um bloqueio de metadados ), o que pode acontecer muito mais tarde.
EDIT: Aparentemente esta avaliação foi muito pessimista. Eu tenho feito vários testes mysqlslaprealizando operações pesadas na tabela ( INSERT, UPDATE, DELETEdeclarações e SELECTdeclarações comLIKEpara evitar o uso de índices) em 150 conexões simultâneas simuladas durante a ALTER TABLE ... ADD COLUMNexecução; a criação de perfil mostra bloqueios de metadados, mas com tempos de espera curtos (1 segundo cada), e a alteração da tabela é concluída em cerca de 30 minutos, em comparação com 10 minutos sem nenhuma instrução SQL em execução. Embora isso seja satisfatório, por outro lado, gostaria de saber se é seguro assumir que as instruções DDL não são bloqueantes.
(Provavelmente vale a pena notar que existe um recurso Instant ADD COLUMNno InnoDB , que permite a adição instantânea de uma coluna à tabela (sob restrições específicas), mas não está disponível antes da v10.3.2.)
Sim, ele trava a mesa. Dos documentos no MySQL 8,
E dos documentos que você vinculou , é bastante explícito
Como você disse, você está no 10.2. Portanto, parece que adicionar uma coluna exigirá a reconstrução de toda a tabela.
Quanto ao que acontece quando você não pode receber um cadeado,
Sim, geralmente é isso que acontece durante um bloqueio, mas esteja ciente de que nem sempre é o que acontece. Às vezes, as declarações e transações desistem de esperar. Às vezes, back-ends e pools são colhidos quando estão presos esperando. É sempre mais seguro fazer isso durante o tempo de inatividade, ter tempos limite e detectar erros de bibliotecas quando os tempos limite expirarem. Enquanto você estiver usando transações, as coisas serão revertidas se algo for acionado e não puder ser bloqueado antes do tempo limite - tudo será kosher.
na verdade, depende da tabela alter específica, mas em qualquer caso, sugiro procurar ferramentas de alteração de esquema on-line como ghost (do GitHub) ou pt-online-schema-change (por percona).
Ambas as ferramentas fazem a alteração em uma mesa separada e alternam com a original no final - você pode até manter a antiga para uma reversão rápida.
É uma rota muito mais segura, especialmente para mesas pesadas