Poängen är inte om potentiella dåliga situationer är sannolika. Poängen är om de är möjliga. Så länge det finns en icke-trivial sannolikhet för att problemet uppstår, om det är känt bör det undvikas.
Det är inte så att vi pratar om att ändra ett funktionsanrop på en rad till ett monster på 5000 rader för att hantera ett avlägset möjligt kantfall. Vi pratar om att faktiskt förkorta samtalet till en mer läsbar och mer korrekt användning.
Jag håller med @Mark Baker om att det finns en prestationsövervägande, men eftersom id är en primärnyckel, MAX frågan kommer att vara mycket snabb. Visst, LAST_INSERT_ID() kommer att vara snabbare (eftersom det bara är att läsa från en sessionsvariabel), men bara med en trivial mängd.
Och du behöver inte många användare för att detta ska inträffa. Allt du behöver är många samtidiga förfrågningar (inte ens så många). Om tiden mellan start av infogningen och starten av valet är 50 millisekunder (förutsatt att en transaktionssäker DB-motor) då behöver du bara 20 förfrågningar per sekund för att börja träffa ett problem med detta konsekvent. Poängen är att fönstret för fel är icke-trivialt. Om du säger 20 förfrågningar per sekund (vilket i verkligheten inte är mycket), och antar att den genomsnittliga personen besöker en sida per minut, pratar du bara om 1200 användare. Och det är för att det ska hända regelbundet. Det kan hända en gång med endast 2 användare.
Och direkt från MySQL-dokumentationen på ämnet :
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.