Въпросът не е дали са вероятни потенциални лоши ситуации. Въпросът е дали са възможни. Стига да има нетривиална вероятност проблемът да възникне, ако е известен, трябва да се избягва.
Не е като да говорим за промяна на едноредово извикване на функция в чудовище от 5000 реда, за да се справим с отдалечено възможен крайен случай. Говорим за действително съкращаване на обаждането до по-четливо и по-правилно използване.
Донякъде съм съгласен с @Mark Baker, че има някои съображения за производителност, но тъй като id е първичен ключ, MAX запитването ще бъде много бързо. Разбира се, LAST_INSERT_ID() ще бъде по-бързо (тъй като просто чете от променлива на сесия), но само с незначителна сума.
И не са ви необходими много потребители, за да се случи това. Всичко, от което се нуждаете, е много едновременни заявки (дори не толкова много). Ако времето между началото на вмъкването и началото на избора е 50 милисекунди (ако приемем, че е безопасен за транзакции DB двигател), тогава имате нужда само от 20 заявки в секунда, за да започнете да удряте проблем с това последователно. Въпросът е, че прозорецът за грешка е нетривиален. Ако кажете 20 заявки в секунда (което в действителност не е много) и ако приемем, че средният човек посещава една страница в минута, вие говорите само за 1200 потребители. И това е, за да се случва редовно. Това може да се случи веднъж само с 2 потребители.
И точно от документацията на MySQL на предмет :
You can generate sequences without calling LAST_INSERT_ID(), but the utility of
using the function this way is that the ID value is maintained in the server as
the last automatically generated value. It is multi-user safe because multiple
clients can issue the UPDATE statement and get their own sequence value with the
SELECT statement (or mysql_insert_id()), without affecting or being affected by
other clients that generate their own sequence values.
