重要なのは、潜在的な悪い状況が発生する可能性があるかどうかではありません。重要なのは、それらが可能かどうかです。問題が発生する可能性が自明でない限り、それがわかっている場合は回避する必要があります。
リモートで可能なエッジケースに対処するために、1行の関数呼び出しを5000行のモンスターに変更することについて話しているわけではありません。実際に、呼び出しをより読みやすく、より正確な使用法に短縮することについて話しています。
@Mark Bakerには、パフォーマンスに関する考慮事項があることに同意しますが、id 主キーであるMAX クエリは非常に高速になります。確かに、LAST_INSERT_ID() （セッション変数から読み取るだけなので）高速になりますが、ごくわずかな量だけです。
そして、これが発生するために多くのユーザーを必要としません。必要なのは、多数の同時リクエストです（それほど多くはありません）。 開始の間の時間が 挿入の開始と選択の開始が50ミリ秒（トランザクションセーフなDBエンジンを想定）の場合、これで一貫して問題が発生し始めるには、1秒あたり20リクエストしか必要ありません。重要なのは、エラーのウィンドウが重要であるということです。 1秒あたり20リクエスト（実際にはそれほど多くはありません）と言い、平均的な人が1分あたり1ページにアクセスすると仮定すると、1200ユーザーしか話していません。そして、それはそれが定期的に起こるためです。これは、2人のユーザーで1回発生する可能性があります。
そして、MySQLドキュメントから件名 ：
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.