Илья С, как-то это странно.
INSERT соверенно точно производит проверку первичного ключа и совершенно точно резервирует автоинкремент при его наличии. и только потом производит собственно апдейт. То есть делает то же самое что и апдейт, но при этом ещё всякое. Я не вижу на чем тут может быть потеря производительности у апдейта.
Ну, будет время, попробую посмотреть.
Илья С, ой ну не смеши. какие там "вычисления" - тупой кейс, каждая ветка в три инструкции процессора :)
Это же не во where кейс, а просто для понимания какое число куда писать. Ни один современный проессор его вообще не заметит.
Куда интереснее то что UPDATE - это тоже "Одна чистая операция, поисков ровно столько сколько надо, проверка всегда идёт по PK, либо UK". И она должна быть на самом деле "быстрее" потому что нет предварительной попытки вставить, зарезервировать id, обработки ошибки, и только после этого - апдейт.
Так что тупит твой ламер. Всё как я говорил - меряет сам не знает что, цифры от балды :)
А про INSERT - поверь, не один и не два разработчика больно кусали себе локти, когда у них вместо апдейтов вдруг вставлялась куча левых строк. Не стоит использовать запрос INSERT там где тебе нужен UPDATE. Ну только если ты не эксперт со Stack Overflow :)
INSERT * ON DUPLICATE UPDATE имеет очень четкую область применения. И не нужно его использовать как лайфхак для апдейтов.
Илья С, ну начнем с того, что запрос INSERT ... ON DUPLICATE UPDATE это запрос на вставку. Этот момент упускают все диванные теоретики и любители микробенчмарков со стаковерфлоя, ни разу в жизни свои советы не применявшие на практике. И подходит такой вариант далеко не всегда.
Если же говорить о конкретном запросе, то в данном случае не так важно, что "быстрее". Относительные величины уже будут не принципиальны.
Транзакция - универсальное решение, которое работает для всех случаев с приемлемой скоростью, решая проблему с innodb_flush_log_at_trx_commit, которая тормозит запись в 70-80 раз. И вот если это адское торможение убрать, то дальше уже будет без разницы, как именно вставлять. И уж на выполнении несчастных 20 запросов в микроскопическую таблицу автора разница таки не будет заметна.
Ну и надо всегда помнить, что любители тестирования со стаковерфлоя тестировать-то как раз поголовно и не умеют. И цифры у них могут показывать что угодно.
Вот взял бы и написал раз в жизни подготовленный запрос.
Глядишь, и сам научишься