"ВСТАВКА IGNORE" проти "ВСТАВКА ... НА ДУПЛІКАТИ КЛЮЧОВОГО ОНОВЛЕННЯ"

Під час виконання INSERTоператора з багатьма рядками я хочу пропустити повторювані записи, які в іншому випадку можуть спричинити збій. Після деяких досліджень моїми можливостями є використання будь-якого:

• ON DUPLICATE KEY UPDATE що означає непотрібне оновлення за певну ціну, або
• INSERT IGNORE що має на увазі запрошення для інших видів невдач, щоб пропустити їх без повідомлення.

Я прав у цих припущеннях? Який найкращий спосіб просто пропустити рядки, які можуть спричинити дублікати, і просто продовжити до інших рядків?

Я б рекомендував використовувати INSERT...ON DUPLICATE KEY UPDATE.

Якщо ви використовуєте INSERT IGNORE, рядок насправді не буде вставлено, якщо це призведе до повторення ключа. Але оператор не призведе до помилки. Натомість він генерує попередження. Ці випадки включають:

• Вставка дублікат ключа в шпальтах з PRIMARY KEYабо UNIQUEобмеженнями.
• Вставлення NULL в стовпчик з NOT NULLобмеженням.
• Вставлення рядка в розділену таблицю, але введені вами значення не збігаються з розділом.

Якщо ви використовуєте REPLACE, MySQL фактично робить , за яким DELETEслід INSERTвнутрішньо, який має деякі несподівані побічні ефекти:

• Присвоєно новий ідентифікатор автоматичного збільшення.
• Залежні рядки з іноземними ключами можуть бути видалені (якщо ви використовуєте каскадні іноземні ключі) або іншим чином запобігати REPLACE.
• Тригери, які спрацьовують DELETE, виконуються без потреби.
• Побічні ефекти також поширюються на репліки.

виправлення: як REPLACEі INSERT...ON DUPLICATE KEY UPDATEє нестандартними, власницькими винаходами, характерними для MySQL. ANSI SQL 2003 визначає MERGEоператор, який може вирішити ту саму потребу (і більше), але MySQL не підтримує MERGEзаяву.

Користувач намагався редагувати цю публікацію (редактор відхилив модератори). Редагування намагалося додати претензію, яка INSERT...ON DUPLICATE KEY UPDATEспричиняє присвоєння нового ідентифікатора автоматичного збільшення. Це правда, що новий ідентифікатор генерується , але він не використовується у зміненому рядку.

Дивіться демонстрацію нижче, протестовану на Percona Server 5.5.28. Змінна конфігурація innodb_autoinc_lock_mode=1(за замовчуванням):

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

Сказане вище демонструє, що оператор IODKU виявляє дублікат та викликає оновлення для зміни значення u. Зверніть увагу, AUTO_INCREMENT=3вказує, що ідентифікатор створений, але не використовується в рядку.

Тоді REPLACEяк видаляє початковий рядок і вставляє новий рядок, генеруючи та зберігаючи новий ідентифікатор автоматичного збільшення:

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

Якщо ви хочете побачити, що все це означає, ось вам все це:

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

Первинний ключ базується на обох стовпцях цієї швидкої довідкової таблиці. Первинний ключ вимагає унікальних значень.

Давайте почнемо:

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

Зауважте, що вищезгадане заощадило надто багато додаткової роботи, встановивши стовпець рівним собі, оновлення насправді не потрібно

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

а тепер декілька рядкових тестів:

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

ніяких інших повідомлень не створювалося в консолі, і тепер вони мають ці 4 значення в даних таблиці. Я видалив усе, крім (1,1), щоб я міг перевірити з того самого ігрового поля

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

Так ось у вас це є. Оскільки це було виконано на свіжому столі, майже без даних, а не у виробництві, час виконання був мікроскопічним та неактуальним. Кожен, хто має дані в реальному світі, був би більш ніж бажаний внести їх.

Щось важливо додати: Коли ви користуєтесь INSERT IGNORE і у вас є ключові порушення, MySQL НЕ викликає попередження!

Якщо ви спробуєте, наприклад, вставити 100 записів одночасно, при цьому одна несправна, ви перейдете в інтерактивний режим:

Query OK, 99 rows affected (0.04 sec)

Records: 100 Duplicates: 1 Warnings: 0

Як бачите: Ніяких попереджень! Така поведінка навіть неправильно описана в офіційній Документації Mysql.

Якщо ваш сценарій потрібно повідомити, якщо деякі записи не додано (через ключові порушення), вам потрібно зателефонувати на mysql_info () та проаналізувати його на значення "Дублікати".

Я звичайно використовую INSERT IGNORE, і це виглядає як саме та поведінка, яку ви шукаєте. Поки ви знаєте, що рядки, які могли б викликати конфлікти в індексах, не будуть вставлені, і ви плануєте свою програму відповідно, це не повинно створювати проблем.

Я знаю, що це по-старому, але я додам цю замітку, якщо хто-небудь інший (як я) потрапить на цю сторінку, намагаючись знайти інформацію про INSERT..IGNORE.

Як було сказано вище, якщо ви використовуєте INSERT..IGNORE, помилки, які виникають під час виконання оператора INSERT, замість цього трактуються як попередження.

Одне, що прямо не згадується, - це те, що INSERT..IGNORE призведе до того, що недійсні значення будуть приведені до найближчих значень при вставці (тоді як недійсні значення можуть спричинити скасування запиту, якщо ключове слово IGNORE не було використане).

ON KEY UPDATE DUPLICATE НЕ дійсно в стандарті. Це приблизно так само стандартно, як і ЗАМІНА. Див. SQL MERGE .

По суті обидві команди є альтернативно-синтаксичними версіями стандартних команд.

ReplaceInto здається варіантом. Або ви можете перевірити

IF NOT EXISTS(QUERY) Then INSERT

Це буде вставити або видалити, потім вставити. Я схильний IF NOT EXISTSспершу йти на перевірку.

Потенційна небезпека INSERT IGNORE. Якщо ви намагаєтеся вставити значення VARCHAR довше, то стовпець був визначений з - значення буде урізано та вставлено ВСІМО, якщо включений строгий режим.

При використанні insert ignoreмають SHOW WARNINGS;заяву в кінці вашого набору запиту покаже таблицю з усіма попередженнями, в тому числі , які ідентифікатори були дублікати.

Якщо ви хочете вставити в таблицю та на конфлікт первинного ключа або унікального індексу, він оновлює конфліктуючий рядок замість того, щоб вставляти цей рядок.

Синтаксис:

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

Тепер тут ця заявка на вставку може виглядати інакше, ніж ви бачили раніше. Цей оператор вставлення намагається вставити рядок у table1 зі значеннями a і b у стовпчик колонки1 та колонки2 відповідно.

Давайте глибше розберемося з цим твердженням:

Наприклад: тут стовпчик1 визначається як основний ключ у таблиці1.

Тепер, якщо в table1 немає рядка зі значенням "a" у колонці1. Отже цей вислів буде вставляти рядок у таблицю1.

Тепер, якщо в table1 є рядок зі значенням "a" у колонці2. Таким чином, це твердження оновить значення рядка колонки2 на "с", де значенням стовпець1 є "а".

Тож якщо ви хочете вставити новий рядок, інакше оновіть цей рядок на конфлікт первинного ключа або унікального індексу.
Детальніше читайте за цим посиланням

INSERT...ON DUPLICATE KEY UPDATE бажано запобігати несподіваному керуванню винятками.

Це рішення працює, коли у вас є ** 1 унікальне обмеження **

У моєму випадку я це знаю col1і col2складаю унікальний складений індекс.

Він відслідковує помилку, але не кидає виняток на дублікат. Щодо продуктивності, оновлення на те саме значення є ефективним, як MySQL помічає це і не оновлює його

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

Ідея використовувати такий підхід виникла з коментарів на phpdelusions.net/pdo .