मुद्दा यह नहीं है कि संभावित बुरी स्थितियों की संभावना है या नहीं। बात यह है कि यदि वे संभव हैं। जब तक समस्या होने की गैर-तुच्छ संभावना है, यदि यह ज्ञात है तो इसे टाला जाना चाहिए।
ऐसा नहीं है कि हम दूर से संभव किनारे के मामले से निपटने के लिए एक लाइन फ़ंक्शन कॉल को 5000 लाइन राक्षस में बदलने के बारे में बात कर रहे हैं। हम वास्तव में कॉल को अधिक पठनीय, और अधिक सही उपयोग के लिए छोटा करने के बारे में बात कर रहे हैं।
मैं @ मार्क बेकर से सहमत हूं कि कुछ प्रदर्शन विचार हैं, लेकिन id . के बाद से एक प्राथमिक कुंजी है, MAX क्वेरी बहुत तेज होगी। ज़रूर, LAST_INSERT_ID() तेज़ होगा (चूंकि यह सिर्फ एक सत्र चर से पढ़ रहा है), लेकिन केवल एक छोटी सी राशि से।
और ऐसा होने के लिए आपको बहुत सारे उपयोगकर्ताओं की आवश्यकता नहीं है। आपको बस बहुत सारे समवर्ती अनुरोधों की आवश्यकता है (इतना भी नहीं)। अगर शुरू . के बीच का समय डालने और चयन की शुरुआत 50 मिलीसेकंड (एक लेनदेन सुरक्षित डीबी इंजन मानते हुए) है, तो आपको लगातार इस मुद्दे को मारना शुरू करने के लिए प्रति सेकंड केवल 20 अनुरोधों की आवश्यकता है। मुद्दा यह है कि त्रुटि के लिए खिड़की गैर-तुच्छ है। यदि आप प्रति सेकंड 20 अनुरोध कहते हैं (जो वास्तव में बहुत अधिक नहीं है), और यह मानते हुए कि औसत व्यक्ति प्रति मिनट एक पृष्ठ पर जाता है, तो आप केवल 1200 उपयोगकर्ताओं की बात कर रहे हैं। और यह नियमित रूप से होने के लिए है। यह केवल 2 उपयोगकर्ताओं के साथ एक बार हो सकता है।
और सीधे 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.
