Форум MySQL

Ваши слова меня успокоили. Благодарю, Игopь Вячecлaвoвич.

>точно ли mysql_insert_id возвратит мне последний созданный id или могут быть проблемы при
>большом количестве запросов одновременно?
Точно. Дело в том, что mysql_insert_id() возвращает только тот номер, который был вставлен в рамках текущей сессии, т.е. между INSERT-запросом и вызовом mysql_insert_id() может успеть вставиться еще пяток запросов, но вам будет возвращен номер того, который вставлялся именно вашим запросом.

Верно, уже несколько лет как )

Появился правда ещё один вопрос, я им сам задался щас, когда решил сменить некоторые запросы к базе данных с учётом нововведений и сразу же столкнулся с такой проблемой: раньше-то я заранее знал, какой id будет записан, потому как сначала генерировал его, а уж потом использовал. Сейчас же получится наоборот. Я сначала его запишу, а потом мне нужно узнать какой он. Я так понял мне поможет mysql_insert_id, но вот загвоздка — точно ли mysql_insert_id возвратит мне последний созданный id или могут быть проблемы при большом количестве запросов одновременно?

Вячеслав выше сообщал, что на базу данных он перешел, только механизм AUTO_INCREMENT до сих пор предпочитал не использовать.

То ли еще будет.
Переход с файлов на базу данных открывает колоссальные возможности.

Всех благодарствую.

Я привык к файлам, и потому использовал именно их. Создал функцию, для простого назначения нового id, но новый вариант действительно упрощает жизнь. Что ж, перейду тогда на него. Я немного его потестировал и мне понравился результат.

Спасибо.

Совершенно с Вами согласен.

>Разрешение у сервера более одной микросекунды, так что, как мне кажется, совпадение технически невозможно.
>Разве не так?

С одной стороны, даже если совпадение невозможно сейчас, нет гарантии, что это не случится в будущем.
С другой, для хранения точного времени в достаточно длинном интервале потребуется поле большей разрядности.
Поиск по такому полю потребует более толстого ингдекса и проходить будет медленее.

Кроме того, использование секвенции позволяет определять факт удаления строк, выявлять смежные записи, хоть это и не прямое её назначение.
И главное, от очереди запросов все равно никуда не уйти.

Вот и получается, что выгоды от применения времени в качестве ключа - никакой.
А потери есть.

С другой стороны, применение механизма AUTO_INCREMENT в качестве суррогатного первичного ключа никто не навязывает. Если Вы хотите применять метку времени (или еще что-то) - Вы вполне можете так поступить.
Вот только будет ли профит...

> И он будет увеличивать каждый раз число, даже если последняя запись была удалена?

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

Файл обычно дольше одной микросекунды обрабатывается - неприятности вполне могут быть, лучше организовывать очередь, пусть даже простейшую файловую, т.е. писать все в отдельные файлы, которые потом одним процессом упаковывать в единый файл. В этом случае гарантировано ничего теряться и биться не будет.