Il punto non è se sono probabili potenziali brutte situazioni. Il punto è se sono possibili. Finché esiste una probabilità non banale che si verifichi il problema, se è noto dovrebbe essere evitato.
Non è che stiamo parlando di cambiare una chiamata di funzione di una linea in un mostro di 5000 linee per affrontare un caso limite remotamente possibile. Stiamo parlando di ridurre effettivamente la chiamata a un utilizzo più leggibile e più corretto.
Sono d'accordo con @Mark Baker sul fatto che ci siano alcune considerazioni sulle prestazioni, ma poiché id è una chiave primaria, il MAX la query sarà molto veloce. Certo, il LAST_INSERT_ID() sarà più veloce (dal momento che sta solo leggendo da una variabile di sessione), ma solo di un importo insignificante.
E non hai bisogno di molti utenti perché ciò avvenga. Tutto ciò di cui hai bisogno sono molte richieste simultanee (nemmeno così tante). Se il tempo tra l'inizio dell'inserimento e l'inizio della selezione è di 50 millisecondi (supponendo un motore DB sicuro per le transazioni), quindi sono necessarie solo 20 richieste al secondo per iniziare a riscontrare un problema con questo in modo coerente. Il punto è che la finestra di errore non è banale. Se dici 20 richieste al secondo (che in realtà non sono molte) e supponendo che la persona media visiti una pagina al minuto, stai parlando solo di 1200 utenti. E questo è che avvenga regolarmente. Potrebbe succedere una volta con solo 2 utenti.
E direttamente dalla documentazione MySQL su il soggetto :
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.
