Nejde o to, zda jsou pravděpodobné potenciální špatné situace. Jde o to, jestli jsou možné. Pokud existuje netriviální pravděpodobnost výskytu problému, je třeba se mu vyhnout, pokud je známa.
Není to tak, že bychom mluvili o změně volání funkce jednoho řádku na monstrum s 5000 řádky, abychom se vypořádali se vzdáleně možným případem okraje. Mluvíme o skutečném zkrácení volání na čitelnější a správnější použití.
Souhlasím s @Markem Bakerem, že je třeba zvážit výkon, ale protože id je primární klíč, MAX dotaz bude velmi rychlý. Jistě, LAST_INSERT_ID() bude rychlejší (protože jde jen o čtení z proměnné relace), ale jen o triviální množství.
A k tomu nepotřebujete mnoho uživatelů. Vše, co potřebujete, je hodně souběžných požadavků (ani ne tolik). Pokud je čas mezi zahájením vložení a začátek výběru je 50 milisekund (za předpokladu, že databázový engine bezpečný pro transakce), pak potřebujete pouze 20 požadavků za sekundu, abyste s tímto začali konzistentně narážet na problém. Jde o to, že okno pro chyby je netriviální. Pokud řeknete 20 požadavků za sekundu (což ve skutečnosti není mnoho) a za předpokladu, že průměrný člověk navštíví jednu stránku za minutu, mluvíte pouze o 1200 uživatelích. A to proto, aby se to dělo pravidelně. Může se to stát jednou pouze se 2 uživateli.
A přímo z dokumentace MySQL na předmět :
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.