Nie chodzi o to, czy prawdopodobne są potencjalne złe sytuacje. Chodzi o to, czy są możliwe. Tak długo, jak istnieje nietrywialne prawdopodobieństwo wystąpienia problemu, jeśli wiadomo, należy tego unikać.
To nie jest tak, że mówimy o zmianie jednoliniowego wywołania funkcji na 5000-liniowego potwora, aby poradzić sobie ze zdalnie możliwym przypadkiem brzegowym. Mówimy o skróceniu połączenia do bardziej czytelnego i bardziej poprawnego użycia.
W pewnym sensie zgadzam się z @Mark Bakerem, że jest trochę uwagi na wydajność, ale ponieważ id jest kluczem podstawowym, MAX zapytanie będzie bardzo szybkie. Jasne, LAST_INSERT_ID() będzie szybszy (ponieważ tylko odczytuje ze zmiennej sesji), ale tylko o niewielką ilość.
I do tego nie potrzeba wielu użytkowników. Wszystko czego potrzebujesz to dużo jednoczesnych żądań (nawet nie tak dużo). Jeśli czas między rozpoczęciem wstawiania, a początek zaznaczania to 50 milisekund (zakładając, że silnik bazy danych bezpieczny dla transakcji), wtedy potrzebujesz tylko 20 żądań na sekundę, aby zacząć konsekwentnie trafiać na problem. Chodzi o to, że okno na błąd nie jest trywialne. Jeśli powiesz 20 żądań na sekundę (co w rzeczywistości nie jest dużo) i zakładając, że przeciętna osoba odwiedza jedną stronę na minutę, mówisz tylko o 1200 użytkownikach. A to po to, żeby działo się to regularnie. Może się to zdarzyć raz przy tylko 2 użytkownikach.
I bezpośrednio z dokumentacji MySQL na temat :
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.
