Vấn đề là không nên nếu các tình huống xấu tiềm ẩn có thể xảy ra. Vấn đề là nếu họ có thể. Miễn là có một xác suất không nhỏ về sự cố xảy ra, nếu nó được biết thì nên tránh.
Nó không giống như chúng ta đang nói về việc thay đổi một lệnh gọi hàm một dòng thành một con quái vật 5000 dòng để đối phó với một trường hợp cạnh có thể xảy ra từ xa. Chúng ta đang nói về việc thực sự rút ngắn cuộc gọi thành cách sử dụng dễ đọc hơn và đúng đắn hơn.
Tôi đồng ý với @Mark Baker rằng có một số cân nhắc về hiệu suất, nhưng vì id là khóa chính, MAX truy vấn sẽ rất nhanh chóng. Chắc chắn rồi, LAST_INSERT_ID() sẽ nhanh hơn (vì nó chỉ đọc từ một biến phiên), nhưng chỉ với một số lượng nhỏ.
Và bạn không cần nhiều người dùng để điều này xảy ra. Tất cả những gì bạn cần là nhiều yêu cầu đồng thời (thậm chí không nhiều như vậy). Nếu thời gian giữa bắt đầu của phần chèn và thời gian bắt đầu lựa chọn là 50 mili giây (giả sử công cụ DB an toàn cho giao dịch), thì bạn chỉ cần 20 yêu cầu mỗi giây để bắt đầu khắc phục sự cố với điều này một cách nhất quán. Vấn đề là cửa sổ lỗi không phải là nhỏ. Nếu bạn nói 20 yêu cầu mỗi giây (thực tế là không nhiều) và giả sử rằng một người trung bình truy cập một trang mỗi phút, bạn chỉ nói 1200 người dùng. Và đó là điều để nó diễn ra thường xuyên. Nó có thể xảy ra một lần với chỉ 2 người dùng.
Và ngay từ Tài liệu MySQL về chủ đề :
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.
