"INSERIR IGNORAR" vs "INSERIR ... NA DUPLICAÇÃO DA CHAVE DE ATUALIZAÇÃO"

Ao executar uma INSERTinstrução com muitas linhas, desejo pular entradas duplicadas que, de outra forma, causariam falhas. Após algumas pesquisas, minhas opções parecem ser o uso de:

• ON DUPLICATE KEY UPDATE o que implica uma atualização desnecessária a algum custo, ou
• INSERT IGNORE o que implica um convite para que outros tipos de falha não sejam anunciados.

Estou certo nessas suposições? Qual é a melhor maneira de simplesmente pular as linhas que podem causar duplicatas e continuar nas outras linhas?

Eu recomendaria usar INSERT...ON DUPLICATE KEY UPDATE.

Se você usar INSERT IGNORE, a linha não será realmente inserida se resultar em uma chave duplicada. Mas a instrução não irá gerar um erro. Em vez disso, gera um aviso. Esses casos incluem:

• Inserir uma chave duplicada em colunas com PRIMARY KEYou UNIQUErestrições.
• Inserir um NULL em uma coluna com uma NOT NULLrestrição.
• Inserir uma linha em uma tabela particionada, mas os valores inseridos não são mapeados para uma partição.

Se você usa REPLACE, o MySQL realmente faz um DELETEseguido por um INSERTinternamente, o que tem alguns efeitos colaterais inesperados:

• Um novo ID de incremento automático é alocado.
• Linhas dependentes com chaves estrangeiras podem ser excluídas (se você usar chaves estrangeiras em cascata) ou impedir a REPLACE.
• Os gatilhos que disparam DELETEsão executados desnecessariamente.
• Os efeitos colaterais também são propagados para réplicas.

correção: tanto REPLACEe INSERT...ON DUPLICATE KEY UPDATEestão fora do padrão, proprietária invenções específico para MySQL. ANSI SQL 2003 define uma MERGEdeclaração que pode resolver a mesma necessidade (e mais), mas o MySQL não suporta a MERGEdeclaração.

Um usuário tentou editar esta postagem (a edição foi rejeitada pelos moderadores). A edição tentou adicionar uma reivindicação que INSERT...ON DUPLICATE KEY UPDATEfaz com que um novo ID de incremento automático seja alocado. É verdade que o novo ID é gerado , mas não é usado na linha alterada.

Veja a demonstração abaixo, testada com o Percona Server 5.5.28. A variável de configuração innodb_autoinc_lock_mode=1(o padrão):

mysql> create table foo (id serial primary key, u int, unique key (u));
mysql> insert into foo (u) values (10);
mysql> select * from foo;
+----+------+
| id | u    |
+----+------+
|  1 |   10 |
+----+------+

mysql> show create table foo\G
CREATE TABLE `foo` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `u` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `u` (`u`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1

mysql> insert into foo (u) values (10) on duplicate key update u = 20;
mysql> select * from foo;
+----+------+
| id | u    |
+----+------+
|  1 |   20 |
+----+------+

mysql> show create table foo\G
CREATE TABLE `foo` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `u` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `u` (`u`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1

O exemplo acima demonstra que a instrução IODKU detecta a duplicata e chama a atualização para alterar o valor de u. Observe que AUTO_INCREMENT=3indica que um ID foi gerado, mas não usado na linha.

Considerando REPLACEque exclui a linha original e insere uma nova linha, gerando e armazenando um novo ID de incremento automático:

mysql> select * from foo;
+----+------+
| id | u    |
+----+------+
|  1 |   20 |
+----+------+
mysql> replace into foo (u) values (20);
mysql> select * from foo;
+----+------+
| id | u    |
+----+------+
|  3 |   20 |
+----+------+

Caso você queira ver o que tudo isso significa, aqui está um golpe por golpe:

CREATE TABLE `users_partners` (
  `uid` int(11) NOT NULL DEFAULT '0',
  `pid` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`uid`,`pid`),
  KEY `partner_user` (`pid`,`uid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

A chave primária é baseada nas duas colunas desta tabela de referência rápida. Uma chave primária requer valores exclusivos.

Vamos começar:

INSERT INTO users_partners (uid,pid) VALUES (1,1);
...1 row(s) affected

INSERT INTO users_partners (uid,pid) VALUES (1,1);
...Error Code : 1062
...Duplicate entry '1-1' for key 'PRIMARY'

INSERT IGNORE INTO users_partners (uid,pid) VALUES (1,1);
...0 row(s) affected

INSERT INTO users_partners (uid,pid) VALUES (1,1) ON DUPLICATE KEY UPDATE uid=uid
...0 row(s) affected

observe que o acima economizou muito trabalho extra ao definir a coluna igual a si mesma, nenhuma atualização realmente necessária

REPLACE INTO users_partners (uid,pid) VALUES (1,1)
...2 row(s) affected

e agora alguns testes de várias linhas:

INSERT INTO users_partners (uid,pid) VALUES (1,1),(1,2),(1,3),(1,4)
...Error Code : 1062
...Duplicate entry '1-1' for key 'PRIMARY'

INSERT IGNORE INTO users_partners (uid,pid) VALUES (1,1),(1,2),(1,3),(1,4)
...3 row(s) affected

nenhuma outra mensagem foi gerada no console e agora possui esses 4 valores nos dados da tabela. Eu apaguei tudo, exceto (1,1), para poder testar no mesmo campo de jogo

INSERT INTO users_partners (uid,pid) VALUES (1,1),(1,2),(1,3),(1,4) ON DUPLICATE KEY UPDATE uid=uid
...3 row(s) affected

REPLACE INTO users_partners (uid,pid) VALUES (1,1),(1,2),(1,3),(1,4)
...5 row(s) affected

Então aí está. Como tudo foi realizado em uma tabela nova, quase sem dados e sem produção, os tempos de execução foram microscópicos e irrelevantes. Qualquer pessoa com dados do mundo real seria mais que bem-vinda para contribuir com eles.

Algo importante a acrescentar: Ao usar o INSERT IGNORE e você tem violações de chave, o MySQL NÃO gera um aviso!

Se você tentar, por exemplo, inserir 100 registros por vez, com um defeituoso, entrará no modo interativo:

Query OK, 99 rows affected (0.04 sec)

Records: 100 Duplicates: 1 Warnings: 0

Como você vê: sem avisos! Esse comportamento é mesmo descrito incorretamente na documentação oficial do Mysql.

Se seu script precisar ser informado, se alguns registros não foram adicionados (devido a violações de teclas), você deve chamar mysql_info () e analisá-lo para o valor "Duplicados".

Eu uso rotineiramente INSERT IGNOREe parece exatamente o tipo de comportamento que você também está procurando. Desde que você saiba que as linhas que causariam conflitos de índice não serão inseridas e você planeje seu programa adequadamente, isso não deverá causar problemas.

Sei que isso é antigo, mas adicionarei esta observação caso alguém (como eu) chegue a esta página enquanto tenta encontrar informações sobre INSERT..IGNORE.

Como mencionado acima, se você usar INSERT..IGNORE, os erros que ocorrem durante a execução da instrução INSERT serão tratados como avisos.

Uma coisa que não é mencionada explicitamente é que INSERT..IGNORE fará com que valores inválidos sejam ajustados aos valores mais próximos quando inseridos (enquanto valores inválidos causariam a interrupção da consulta se a palavra-chave IGNORE não fosse usada).

ON DUPLICATE KEY UPDATE não está realmente no padrão. É tão padrão quanto REPLACE. Consulte SQL MERGE .

Essencialmente, ambos os comandos são versões de sintaxe alternativa dos comandos padrão.

ReplaceInto parece ser uma opção. Ou você pode verificar com

IF NOT EXISTS(QUERY) Then INSERT

Isto irá inserir ou excluir e depois inserir. Costumo fazer um IF NOT EXISTScheque primeiro.

Perigo potencial de INSERIR IGNORAR. Se você estiver tentando inserir um valor VARCHAR por mais tempo, a coluna foi definida com - o valor será truncado e inserido, mesmo que o modo estrito esteja ativado.

Se usar insert ignoreuma SHOW WARNINGS;declaração no final do seu conjunto de consultas, será exibida uma tabela com todos os avisos, incluindo quais IDs foram as duplicatas.

Se você deseja inserir na tabela e no conflito da chave primária ou do índice exclusivo, ele atualizará a linha conflitante em vez de inseri-la.

Sintaxe:

insert into table1 set column1 = a, column2 = b on duplicate update column2 = c;

Agora aqui, essa instrução de inserção pode parecer diferente do que você viu anteriormente. Esta instrução de inserção tentando inserir uma linha na tabela1 com o valor de aeb na coluna column1 e column2 respectivamente.

Vamos entender essa afirmação em profundidade:

Por exemplo: aqui coluna1 é definida como a chave primária na tabela1.

Agora, se na tabela1 não houver linha com o valor "a" na coluna1. Portanto, esta instrução irá inserir uma linha na tabela1.

Agora, se na tabela1 houver uma linha com o valor "a" na coluna2. Portanto, essa instrução atualizará o valor da coluna2 da linha com "c", onde o valor da coluna1 é "a".

Portanto, se você deseja inserir uma nova linha, atualize essa linha no conflito da chave primária ou do índice exclusivo.
Leia mais neste link

INSERT...ON DUPLICATE KEY UPDATE é preferido para impedir o gerenciamento inesperado de exceções.

Esta solução funciona quando você possui ** 1 restrição exclusiva **

No meu caso, eu sei disso col1e col2faço um índice composto exclusivo.

Ele controla o erro, mas não lança uma exceção em duplicado. Em relação ao desempenho, a atualização com o mesmo valor é eficiente, pois o MySQL percebe isso e não o atualiza

INSERT INTO table
  (col1, col2, col3, col4)
VALUES
  (?, ?, ?, ?)
ON DUPLICATE KEY UPDATE
    col1 = VALUES(col1),
    col2 = VALUES(col2)

A idéia de usar essa abordagem veio dos comentários em phpdelusions.net/pdo .