MySQL में INT और UUID के बीच अंतर

UUID एक सार्वभौमिक विशिष्ट पहचानकर्ता लौटाता है (उम्मीद है कि अगर किसी अन्य डीबी में भी आयात किया जाए तो यह अद्वितीय भी होगा)।

MySQL doc से उद्धृत करने के लिए (जोर मेरा):

दूसरी ओर एक साधारण INT प्राथमिक आईडी कुंजी (उदा. AUTO_INCREMENT ) एक अद्वितीय पूर्णांक लौटाएगा विशिष्ट DB और DB तालिका के लिए, लेकिन जो सार्वभौमिक रूप से अद्वितीय नहीं है (इसलिए यदि किसी अन्य डीबी संभावना में आयात किया जाता है तो प्राथमिक कुंजी संघर्ष होंगे)।

प्रदर्शन के संदर्भ में, auto-increment . का उपयोग करके कोई ध्यान देने योग्य अंतर नहीं होना चाहिए UUID से अधिक . अधिकांश पोस्ट (इस साइट के लेखकों द्वारा कुछ सहित), इस तरह बताते हैं। बेशक UUID इसमें थोड़ा अधिक समय (और स्थान) लग सकता है, लेकिन यह अधिकांश (यदि सभी नहीं) मामलों के लिए एक प्रदर्शन बाधा नहीं है। Primary Key के रूप में एक कॉलम रखना दोनों विकल्पों को प्रदर्शन के बराबर wrt बनाना चाहिए। नीचे संदर्भ देखें:

1. टू UUID या नहीं UUID ?
2. मिथक, GUID बनाम Autoincrement
3. प्रदर्शन:UUID बनाम auto-increment केकफ़्पी-mysql में
4. UUID MySQL में प्रदर्शन?
5. प्राथमिक कुंजियां:ID s बनाम GUID s (कोडिंग हॉरर)

(UUID बनाम auto-increment प्रदर्शन के परिणाम, मिथक, GUID से अनुकूलित बनाम Autoincrement )

UUID पक्ष / विपक्ष (प्राथमिक कुंजियां:ID से अनुकूलित s बनाम GUID एस )

नोट

मैं उल्लेखित संदर्भों को ध्यान से पढ़ूंगा और तय करूंगा कि UUID . का उपयोग करना है या नहीं या मेरे उपयोग के मामले के आधार पर नहीं। उस ने कहा, कई मामलों में UUID s वास्तव में बेहतर होगा। उदाहरण के लिए कोई UUID generate उत्पन्न कर सकता है डेटाबेस का उपयोग/एक्सेस किए बिना, या यहां तक ​​कि UUID . का भी उपयोग करें s जिन्हें पूर्व-गणना की गई है और/या कहीं और संग्रहीत किया गया है। साथ ही आप ID की चिंता किए बिना अपने डेटाबेस स्कीमा और/या क्लस्टरिंग योजना को आसानी से सामान्य/अपडेट कर सकते हैं टूट रहा है और विरोध पैदा कर रहा है।

संभावित टकरावों के संदर्भ में, उदाहरण के लिए v4 UUIDS (यादृच्छिक) का उपयोग करना, डुप्लीकेट खोजने की संभावना 103 ट्रिलियन संस्करण-4 में UUIDs अरबों में एक होता है।