GUID उच्च यादृच्छिकता के कारण संकुल कुंजियों के रूप में समस्याग्रस्त हैं। पॉल रान्डल ने पिछले टेक्नेट मैगज़ीन क्यू एंड ए कॉलम में इस मुद्दे को संबोधित किया था:मैं क्लस्टर इंडेक्स कुंजी के रूप में एक GUID का उपयोग करना चाहता हूं, लेकिन अन्य तर्क दे रहे हैं कि इससे इंडेक्स के साथ प्रदर्शन समस्याएं हो सकती हैं। क्या यह सच है और यदि हां, तो क्या आप समझा सकते हैं कि क्यों?
अब ध्यान रखें कि चर्चा विशेष रूप से क्लस्टर . के बारे में है सूचकांक आप कहते हैं कि आप कॉलम को 'आईडी' के रूप में उपयोग करना चाहते हैं, यह स्पष्ट नहीं है कि क्या आपका मतलब क्लस्टर कुंजी या सिर्फ प्राथमिक कुंजी के रूप में है। आम तौर पर दो ओवरलैप होते हैं, इसलिए मुझे लगता है कि आप इसे क्लस्टर इंडेक्स के रूप में उपयोग करना चाहते हैं। मेरे द्वारा ऊपर बताए गए लेख के लिंक में इसके खराब विकल्प के कारण बताए गए हैं।
गैर-संकुल अनुक्रमणिका के लिए GUID में अभी भी कुछ समस्याएँ हैं, लेकिन लगभग उतनी बड़ी नहीं हैं जब वे तालिका की सबसे बाईं संकुलित कुंजी होती हैं। फिर से, GUID की यादृच्छिकता पृष्ठ विभाजन और विखंडन का परिचय देती है, चाहे वह केवल गैर-संकुल सूचकांक स्तर पर हो (एक बहुत छोटी समस्या)।
GUID उपयोग के आसपास कई शहरी किंवदंतियाँ हैं जो एक int (4 बाइट्स) की तुलना में उनके आकार (16 बाइट्स) के आधार पर उनकी निंदा करती हैं और यदि उनका उपयोग किया जाता है तो भयानक प्रदर्शन कयामत का वादा करता है। यह थोड़ा अतिशयोक्तिपूर्ण है। एक उचित रूप से डिज़ाइन किए गए डेटा मॉडल पर, आकार 16 की कुंजी अभी भी एक बहुत ही बेहतर कुंजी हो सकती है। जबकि यह सच है कि int से 4 गुना बड़ा होने के परिणामस्वरूप कम घनत्व वाले गैर-पत्ती वाले पृष्ठ अधिक बनते हैं अनुक्रमित में, यह अधिकांश तालिकाओं के लिए वास्तविक चिंता का विषय नहीं है। बी-पेड़ संरचना एक स्वाभाविक रूप से संतुलित पेड़ है और गहराई ट्री ट्रैवर्सल का शायद ही कभी कोई मुद्दा होता है, इसलिए GUID कुंजी के आधार पर एक INT कुंजी के विपरीत मूल्य की मांग करना प्रदर्शन में समान है। एक लीफ-पेज ट्रैवर्सल (अर्थात एक टेबल स्कैन) गैर-पत्ती पृष्ठों को नहीं देखता है, और पृष्ठ आकार पर GUID आकार का प्रभाव आम तौर पर काफी छोटा होता है, क्योंकि रिकॉर्ड स्वयं पेश किए गए अतिरिक्त 12 बाइट्स से काफी बड़ा होता है। GUID द्वारा। तो मैं नमक के बड़े अनाज के साथ '16 बाइट्स बनाम 4' के आधार पर सुनने की सलाह लेता हूं। अलग-अलग मामले पर विश्लेषण करें और तय करें कि क्या आकार के प्रभाव से वास्तविक फर्क पड़ता है:कितने अन्य कॉलम तालिका में हैं (अर्थात लीफ पृष्ठों पर GUID आकार का कितना प्रभाव पड़ता है) और कितने संदर्भ इसका उपयोग कर रहे हैं (अर्थात कितने अन्य तालिकाओं में वृद्धि होगी क्योंकि उन्हें एक बड़ी विदेशी कुंजी संग्रहीत करने की आवश्यकता होती है)।
मैं इन सभी विवरणों को GUIDs की अस्थायी रक्षा के रूप में कह रहा हूं क्योंकि हाल ही में उन्हें बहुत खराब प्रेस मिल रही है और कुछ अवांछनीय हैं। उनके पास अपनी खूबियां हैं और किसी भी वितरित प्रणाली में अपरिहार्य हैं (जिस क्षण आप डेटा आंदोलन की बात कर रहे हैं, चाहे वह प्रतिकृति या सिंक फ्रेमवर्क या जो भी हो)। मैंने देखा है कि GUID की खराब प्रतिष्ठा के आधार पर खराब निर्णय लिए जा रहे हैं जब उन्हें उचित विचार के बिना छोड़ दिया गया था। लेकिन यह सच है, यदि आपको GUID को क्लस्टर कुंजी के रूप में उपयोग करना है, तो सुनिश्चित करें कि आप यादृच्छिकता समस्या का समाधान करते हैं:अनुक्रमिक गाइड का उपयोग करें जब संभव हो।
और अंत में, अपने प्रश्न का उत्तर देने के लिए:यदि आपके पास विशिष्ट नहीं है GUID का उपयोग करने का कारण, INT का उपयोग करें।
