"INSERISCI IGNORA" vs "INSERISCI ... IN AGGIORNAMENTO CHIAVE DUPLICATO"

Mentre eseguo INSERTun'istruzione con molte righe, voglio saltare voci duplicate che altrimenti causerebbero un errore. Dopo alcune ricerche, le mie opzioni sembrano essere l'uso di:

• ON DUPLICATE KEY UPDATE che implica un aggiornamento non necessario a un certo costo, oppure
• INSERT IGNORE il che implica un invito per altri tipi di fallimento a scivolare senza preavviso.

Ho ragione su questi presupposti? Qual è il modo migliore per saltare semplicemente le righe che potrebbero causare duplicati e continuare semplicemente con le altre righe?

Consiglierei di usare INSERT...ON DUPLICATE KEY UPDATE.

Se si utilizza INSERT IGNORE, la riga non verrà effettivamente inserita se risulta in una chiave duplicata. Ma la dichiarazione non genererà un errore. Genera invece un avviso. Questi casi includono:

• Inserimento di una chiave duplicata in colonne con PRIMARY KEYo UNIQUEvincoli.
• Inserimento di un NULL in una colonna con un NOT NULLvincolo.
• Inserimento di una riga in una tabella partizionata, ma i valori inseriti non vengono mappati su una partizione.

Se lo usi REPLACE, MySQL esegue effettivamente un DELETEseguito INSERTinternamente, che ha alcuni effetti collaterali imprevisti:

• Viene assegnato un nuovo ID di incremento automatico.
• Le righe dipendenti con chiavi esterne possono essere eliminate (se si utilizzano chiavi esterne a cascata) oppure impedire il REPLACE.
• I trigger che si accendono DELETEvengono eseguiti inutilmente.
• Gli effetti collaterali si propagano anche alle repliche.

correzione: entrambe REPLACEe INSERT...ON DUPLICATE KEY UPDATEsono invenzioni proprietarie non standard specifiche di MySQL. ANSI SQL 2003 definisce MERGEun'istruzione che può risolvere lo stesso bisogno (e altro), ma MySQL non supporta l' MERGEistruzione.

Un utente ha provato a modificare questo post (la modifica è stata rifiutata dai moderatori). La modifica ha tentato di aggiungere un reclamo che INSERT...ON DUPLICATE KEY UPDATEdetermina l'allocazione di un nuovo ID di autoincremento. È vero che il nuovo ID viene generato , ma non viene utilizzato nella riga modificata.

Vedi la dimostrazione di seguito, testata con Percona Server 5.5.28. La variabile di configurazione innodb_autoinc_lock_mode=1(impostazione predefinita):

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

Quanto sopra dimostra che l'istruzione IODKU rileva il duplicato e richiama l'aggiornamento per modificare il valore di u. Nota che AUTO_INCREMENT=3indica che è stato generato un ID, ma non utilizzato nella riga.

Considerando REPLACEche elimina la riga originale e inserisce una nuova riga, generando e memorizzando un nuovo ID di incremento automatico:

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

Se vuoi vedere cosa significa tutto questo, ecco un colpo alla volta di tutto:

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

La chiave primaria si basa su entrambe le colonne di questa tabella di riferimento rapido. Una chiave primaria richiede valori univoci.

Cominciamo:

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

notare che quanto sopra ha risparmiato troppo lavoro extra impostando la colonna uguale a se stessa, nessun aggiornamento effettivamente necessario

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

e ora alcuni test su più righe:

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

nessun altro messaggio è stato generato nella console e ora ha quei 4 valori nei dati della tabella. Ho eliminato tutto tranne (1,1) in modo da poter provare dallo stesso campo di gioco

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

Così il gioco è fatto. Dal momento che tutto ciò è stato eseguito su un nuovo tavolo quasi privo di dati e non in produzione, i tempi di esecuzione erano microscopici e irrilevanti. Chiunque disponga di dati del mondo reale sarebbe più che benvenuto a contribuire.

Qualcosa di importante da aggiungere: quando si utilizza INSERT IGNORE e si verificano violazioni chiave, MySQL NON genera un avviso!

Se, ad esempio, provi a inserire 100 record alla volta, con uno difettoso, otterrai la modalità interattiva:

Query OK, 99 rows affected (0.04 sec)

Records: 100 Duplicates: 1 Warnings: 0

Come vedi: nessun avvertimento! Questo comportamento è persino erroneamente descritto nella documentazione ufficiale di Mysql.

Se il tuo script deve essere informato, se alcuni record non sono stati aggiunti (a causa di violazioni chiave) devi chiamare mysql_info () e analizzarlo per il valore "Duplicati".

Uso abitualmente INSERT IGNOREe suona esattamente come il tipo di comportamento che stai cercando. Finché sai che le righe che causerebbero conflitti di indice non verranno inserite e pianifichi il tuo programma di conseguenza, non dovrebbero causare problemi.

So che è vecchio, ma aggiungerò questa nota nel caso in cui altri (come me) arrivino a questa pagina mentre provano a trovare informazioni su INSERT..IGNORE.

Come accennato in precedenza, se si utilizza INSERT..IGNORE, gli errori che si verificano durante l'esecuzione dell'istruzione INSERT vengono invece considerati avvisi.

Una cosa che non è esplicitamente menzionata è che INSERT..IGNORE causerà valori non validi verranno adattati ai valori più vicini quando inseriti (mentre valori non validi provocherebbero l'interruzione della query se la parola chiave IGNORE non fosse utilizzata).

ON DUPLICATE KEY UPDATE non è proprio nello standard. È standard come REPLACE. Vedi SQL MERGE .

Essenzialmente entrambi i comandi sono versioni di sintassi alternative dei comandi standard.

ReplaceSembra un'opzione. Oppure puoi verificare con

IF NOT EXISTS(QUERY) Then INSERT

Questo inserirà o eliminerà quindi inserirà. Tendo a fare un IF NOT EXISTScontrollo prima.

Potenziale pericolo di INSERT IGNORE. Se stai cercando di inserire un valore VARCHAR più a lungo della colonna è stata definita con - il valore verrà troncato e inserito ANCHE SE la modalità rigorosa è abilitata.

Se l'utilizzo di insert ignoreuna SHOW WARNINGS;dichiarazione alla fine del set di query mostrerà una tabella con tutti gli avvisi, inclusi gli ID che erano i duplicati.

Se si desidera inserire nella tabella e nel conflitto della chiave primaria o dell'indice univoco, aggiornerà la riga in conflitto invece di inserire quella riga.

Sintassi:

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

Ora qui, questa dichiarazione di inserimento potrebbe avere un aspetto diverso da quello che hai visto in precedenza. Questa istruzione insert tenta di inserire una riga nella tabella1 con il valore di aeb rispettivamente nella colonna1 e nella colonna2.

Comprendiamo in profondità questa affermazione:

Ad esempio: qui la colonna1 è definita come chiave primaria nella tabella1.

Ora se nella tabella1 non c'è riga con il valore "a" nella colonna1. Quindi questa affermazione inserirà una riga nella tabella1.

Ora se nella tabella1 c'è una riga con il valore "a" nella colonna2. Quindi questa affermazione aggiornerà il valore column2 della riga con "c" dove il valore column1 è "a".

Quindi, se si desidera inserire una nuova riga, aggiornare quella riga in caso di conflitto tra la chiave primaria o l'indice univoco.
Maggiori informazioni su questo link

INSERT...ON DUPLICATE KEY UPDATE è preferito per impedire la gestione imprevista delle eccezioni.

Questa soluzione funziona solo con ** 1 vincolo univoco **

Nel mio caso lo so col1ecol2 creo un indice composito unico.

Tiene traccia dell'errore, ma non genera un'eccezione per i duplicati. Per quanto riguarda le prestazioni, l'aggiornamento con lo stesso valore è efficiente poiché MySQL lo nota e non lo aggiorna

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

L'idea di utilizzare questo approccio è nata dai commenti su phpdelusions.net/pdo .