Я рекомендовал бы использовать INSERT...ON DUPLICATE KEY UPDATE
.
, Если Вы используете INSERT IGNORE
, затем строка не будет на самом деле вставлена, если она приведет к дублирующемуся ключу. Но оператор не генерирует ошибку. Это генерирует предупреждение вместо этого. Эти случаи включают:
PRIMARY KEY
или UNIQUE
ограничения. NOT NULL
ограничение. , Если Вы используете REPLACE
, MySQL на самом деле делает DELETE
сопровождаемый INSERT
внутренне, который имеет некоторые неожиданные побочные эффекты:
REPLACE
. DELETE
, выполняются излишне. исправление: и REPLACE
и INSERT...ON DUPLICATE KEY UPDATE
нестандартные, собственные изобретения, характерные для MySQL. 2003 ANSI SQL определяет MERGE
оператор, который может решить ту же потребность (и больше), но MySQL не поддерживает MERGE
оператор.
пользователь А пытался отредактировать это сообщение (редактирование было отклонено модераторами). Редактирование пыталось добавить заявление что INSERT...ON DUPLICATE KEY UPDATE
причины новый автоинкрементный идентификатор, который будет выделен. Это верно, что новый идентификатор , генерировал , но это не используется в измененной строке.
Посмотрите демонстрацию ниже, протестированный с Сервером Percona 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 обнаруживает дубликат и вызывает обновление для изменения значения [1 118]. Отметьте эти 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 |
+----+------+
Просто не обращайте на это внимания. «Проблема» в том, что не все части Visual Studio правильно различают C ++ и C ++ / CLI. Таким образом, некоторые ключевые слова C ++ / CLI выделяются даже в простом родном C ++. ( array
- другой.)
Это влияет только на подсветку синтаксиса, но не на фактический компилятор.
Таким образом, единственная причина избегать этих слов - это если вы: 1) находите неправильное выделение синтаксиса слишком раздражающим или 2) планируете перенос вашего приложения на C ++ / CLI.
Я не уверен, но думаю, что внутренний спецификатор можно использовать в проектах C ++ / CLI. Итак, поскольку существует разница только в одной настройке проекта между проектом, отличным от C ++ / CLI, и проектом C ++ / CLI, возможно, он выделяется по этой причине.
[Edit] Только что проверено, внутренний ЯВЛЯЕТСЯ ключевым словом в C ++ / CLI и генерирует IL, аналогичный тому, который генерируется проектом C #. Итак, мое первоначальное мышление кажется правильным. Кажется, что это один парсер для всех разновидностей C ++ от Microsoft.
Проблема в том, что синтаксический анализатор, используемый для выделения, не является одним из настоящих синтаксических анализаторов C ++. «Один из», потому что VC ++, C ++ / Za и C ++ / CLI - это три диалекта с разными парсерами. Принтер VS Pretty использует обычный парсер, который не всегда понимает это правильно. Например, у него есть единственный набор ключевых слов, поэтому он всегда предполагает, что "internal" является ключевым словом.