Existem várias razões pelas quais tais "duplicatas" podem ocorrer:
- seus dados são torrados.
- um aplicativo INSERIDO usando o incremento automático, mas depois executou um UPDATE para Modifique manualmente a identidade para um valor diferente, provavelmente existente. este às vezes ocorre com desenvolvedores de aplicativos que estão classificando "por ID" e querem para "corrigir a classificação" (quebrando a consistência).
- uma variação da segunda edição acontece por pessoas que mais tarde adicionam uma restrição "única", depois que registros não exclusivos foram inseridos.
As mensagens de erro referem-se à primeira chave, que na maioria dos esquemas do banco de dados é o primeiro valor. Dê uma olhada na saída de despejo bruto, particularmente as instruções INSERT e verifique por
INSERT INTO ... values (0,...
Analise os números de linha do mysql dump dados nas mensagens de erro.
Exemplo de qual tipo de mysqldump estou esperando:
INSERT INTO foo (id,bar,baz) values (1,2,3);
INSERT INTO foo (id,bar,baz) values (0,4,5);
INSERT INTO foo (id,bar,baz) values (2,6,7);
Em uma instrução INSERT "normal" em um campo de incremento automático, o valor "0" especifica o incremento automático do campo e, portanto, não deve ser exibido em um dump SQL do banco de dados em que um campo de incremento automático está sendo usava. Ao recarregar o banco de dados por meio de um dump SQL, seu dump solicita que o servidor SQL incremente o valor do campo atual em um e insira esse ID. Se alguém tiver atualizado manualmente a identidade para zero depois de INSERIR o registro, seu MySQL Dump também incluirá esse id estranho.
Se você estiver repetindo esse despejo em uma tabela vazia, isso tentará criar os seguintes registros:
1,2,3
2,4,5
2,6,7
Como o campo "id" foi definido como incremento automático exclusivo, o segundo INSERT criará um registro "errado" (esperado: 0,4,5; real: 2,4,5) que entra em conflito com o registro a seguir ( id = 2) e como resultado dá a mensagem de erro.
Em uma variação disso, alguém "manualmente" atualizou a identidade para um valor já existente e depois alterou o registro para "exclusivo". Alterar um tipo de registro para exclusivo não faz a nova validação do MySQL se os dados atuais corresponderem ao requisito, portanto, o erro atrasado. Essa variação pode criar um dump assim:
INSERT INTO foo (id,bar,baz) values (1,2,3);
INSERT INTO foo (id,bar,baz) values (1,4,5);
INSERT INTO foo (id,bar,baz) values (2,6,7);
Tentar inserir a segunda linha falhará devido à restrição exclusiva.
Em ambos os casos, usar "--force" apenas ignora a linha "conflitante" e continua a importação. As linhas "conflitantes" estarão faltando, mas provavelmente as linhas que levam a este conflito estarão lá (mas com um registro de id errado).
Por favor, verifique o seu despejo de banco de dados se a minha ideia corresponder ao seu problema. Se for esse o caso, aqui estão duas soluções alternativas para "fazer funcionar":
-
importe dados em duas etapas, primeiro apenas o esquema, depois os dados. Remova as restrições exclusivas do seu esquema antes de importar os dados, mais tarde, adicione as restrições exclusivas ("ALTER TABLE ... add unique ...").
-
force-import schema e todos os dados, resultando em problemas de restrição "diferentes". Verificar manualmente quais registros estão corretos e reatribuir os errados para seu valor original.
Exemplo para o último problema:
mysql -uuser -ppass --execute "SET UNIQUE_CHECKS=0; source db3.sql" db4
Isso força a importação de todos os registros conflitantes, violando até mesmo restrições reais. Após a importação, você terá várias entradas para esses três registros (600806, 187694 e 1567400), e você terá que classificar manualmente quais são os corretos, verificando o seu despejo, quais dessas "duplicatas" resultaram na Conflito e atualizar manualmente os registros errados "back" para zero (ou qualquer que seja a linha conflitante no despejo disse).
Nos dois cenários, seus dados ainda violam o esquema fornecido: seu esquema diz que os dados são exclusivos, mas não são. No longo prazo, os dados precisam ser corrigidos no nível do aplicativo.