Добрый день, коллеги!

Перечитывая в очередной раз мануал, дочитал до конца описание функции LAST_INSERT_ID
Оказывается разработчики предусмотрели эмуляцию такой интересной фишки из других SQL-движков, как sequences!

Пробовал кто в реальной работе такую эмуляцию? Насколько она работоспособна при мультиюзерной работе?
Какие могут быть "подводные камни"?

Просто решил сделать в одной из своих баз такой счетчик на простенькой табличке с одним автоинкрементным полем:

Если использовать предложенную разработчиками эмуляцию sequences, то вместо двух операций модификации таблицы получаем всего одну - апдейт единственной ее строки. В принципе, на лицо - ускорение. Но, если апдейт неявно блокирует эту единственную запись, то остальным запросам прийдется подождать?!
А в случае с автоинкрементным полем такой блокировки не будет - каждый добавит/удалить свою строку, получив уникальный номер.

Как ваше мнение, коллеги - какой из алгоритмов более работоспособный в реальной работе?

Спасибо!

miksoftOlegROAА в случае с автоинкрементным полем такой блокировки не будетНедавно был топик , в котором даже дедлок описывался, а не просто блокировка.А при чем здесь эта ссылка?!
Ведь мы просто вставляем новую запись, а движек самостоятельно делает инкремент поля. Т.е., мы вообще ничего не блокируем!
В этом алгоритме меня смущает необходимость двух операций модификации таблицы - сначала инсерт и после удаление предыдущей записи. Хотя, имхо, на табличке из пары строчек и только с одним полем эти операции будут выполняться очень быстро.

miksoft1) в InnoDB счетчик нигде не хранится и при рестарте MySQL происходит вычисление MAX(id)+1. В результате будут повторы, если все записи удалять. Т.е. лучше удалять WHERE `id` < @idСпасибо за подсказку - совсем упустил из виду эту особенность автоинкремента для InnoDB!
miksoft2) В InnoDB можно получить вечно растущую таблицу. Сейчас подробностей не найду, но был баг в результате которого при INSERT-е данные пишутся всегда в конец.И что? Мы же удаляем не в порядке хранения а по ключу. Т.е. запрос на удаление записей с индексным полем меньше заданного в любом случае должен отработать правильно? Если он косячит, то однозначно проблемы с индексами! А какие проблемы с индексами могут быть у такой маленькой таблички, которая практически всегда будет находиться в кеше?!

А что по поводу эмуляции sequences , описанной в доке? Никто не пробовал использовать?

miksoftOlegROAА при чем здесь эта ссылка?!Там была схожая ситуация - 15345228 В чем схожая?
Там сначала производился поиск записи с одновременной блокировкой для изменения этой записи. И дедлок происходил, если искомой записи нет, но блокировка уже наложена. И в том случае вообще не использовался автоинкремент.

В нашем же случае НИКАКИХ явных блокировок НЕТ! Мы просто добавляем новую запись. И получаем новое значение автоинкрементируемого поля. И удаление старых записей (скорее всего - только одной старой записи) производим тоже без явной блокировки - нам, в принципе, не важен результат удаления - не удалятся старые записи сейчас, удалятся позже - нам они вообще не интересны и удаляем мы их просто что бы эта табличка не росла.

Поэтому извините, но я что-то никак не вникну - в чем Вы увидели аналогию между этими двумя совершенно разными, имхо, операциями?

miksoftС точки зрения системного администратора - получим хоть и не быстро, но постоянно растущий файл.А, Вы в этом смысле! Я просто не понял - думал про то, что записи не будут удаляться и таблица будет расти в плане увеличения количества записей.