क्लस्टरर्ड GUID PKs के साथ SQL सर्वर डेटाबेस - क्लस्टरर्ड इंडेक्स स्विच करें या अनुक्रमिक (कंघी) GUID पर स्विच करें?

Question

हमारे पास एक डेटाबेस है जिसमें सभी पीके GUID हैं, और अधिकांश पीके तालिका के लिए क्लस्टर्ड इंडेक्स भी हैं। हम जानते हैं कि यह बुरा है (GUID की यादृच्छिक प्रकृति के कारण)। इसलिए, ऐसा लगता है कि यहां मूल रूप से दो विकल्प हैं (पीयूएस के रूप में GUID को फेंकने से कम, जो हम नहीं कर सकते (कम से कम इस समय नहीं))।

• हम GUID पीढ़ी एल्गोरिदम को उदा। एनएचबीर्नेट का उपयोग करता है, जैसा कि this post, या
• में विस्तृत किया गया है, हम सबसे भारी उपयोग के तहत तालिकाओं के लिए, एक अलग क्लस्टर्ड इंडेक्स में बदल सकते हैं, उदाहरण के लिए एक पहचान कॉलम, और "यादृच्छिक" GUID को पीके के रूप में रखें।

क्या इस तरह के परिदृश्य में कोई सामान्य सिफारिशें देना संभव है?

प्रश्न में आवेदन 500+ टेबल है, वर्तमान में लगभग 1,5 मिलियन पंक्तियों में सबसे बड़ा, 500 000 पंक्तियों के आसपास कुछ टेबल, और शेष काफी कम (उनमें से अधिकतर 10 के नीचे) हैं।

इसके अलावा, एप्लिकेशन पहले से ही कई ग्राहक साइटों पर स्थापित है, इसलिए हमें मौजूदा ग्राहक के लिए किसी भी संभावित नकारात्मक प्रभाव को लेना होगा।

धन्यवाद!

Answer 1

हैं:

क्यों GUID की एसक्यूएल सर्वर यहाँ में क्लस्टरिंग कुंजी के रूप में बुरा कर रहे हैं पर किम्बर्ली ट्रिप उत्तम श्रृंखला चेक आउट आप अपना बदल सकते हैं एक अनुक्रमिक guid पीढ़ी के लिए आसानी से guid पीढ़ी तो शायद यह आपके त्वरित जीत विकल्प है। अनुक्रमिक मार्गदर्शिका तालिका पर विखंडन को रोक देगा जबकि आपके क्लस्टर सूचकांक के रूप में शेष रहेगी। अनुक्रमिक मार्गदर्शिका के साथ प्रमुख नकारात्मकता यह है कि वे अनुमान लगाते हैं जो प्रायः वांछित नहीं होते हैं और कारणों को पहली जगह में इस्तेमाल किया जाता है।

यदि आप अपनी क्लस्टर प्राथमिक कुंजी के लिए पहचान मार्ग नीचे जाते हैं और फिर केवल अपने गाइड कॉलम पर एक अनुक्रमणिका है तो आपको अभी भी आपके गाइड इंडेक्स पर बहुत अधिक विखंडन मिलेगा। हालांकि तथ्य यह है कि तालिका अब खंडित नहीं होगी, यह एक बड़ा लाभ होगा।

अंत में, मुझे पता है कि आपने कहा है कि आप अभी यह नहीं कर सकते हैं, लेकिन, यदि आपको ग्रिड का उपयोग इंडेक्स के रूप में करने की आवश्यकता नहीं है तो आप इन सभी समस्याओं को हटा दें।

Answer 2

मेरी राय स्पष्ट है: अपनी क्लस्टरिंग कुंजी के लिए एक आईएनटी पहचान का उपयोग करें। यही कारण है कि अब तक सबसे अच्छा, सबसे इष्टतम क्लस्टरिंग कुंजी के द्वारा है, क्योंकि इसकी:

• छोटे
• स्थिर (कभी नहीं बदलना चाहिए)
• अद्वितीय
• बढ़ती

अनुक्रमिक GUID का निश्चित रूप से एक हैं नियमित यादृच्छिक GUID की तुलना में बहुत बेहतर है, लेकिन अभी भी एक आईएनटी (16 बनाम 4 बाइट) से चार गुना बड़ा है और यह एक कारक होगा यदि आपके टेबल में बहुत सारी पंक्तियां हैं, और उस तालिका में बहुत सारे क्लस्टर्ड इंडेक्स भी हैं । क्लस्टरिंग कुंजी प्रत्येक गैर-क्लस्टर्ड इंडेक्स में जोड़ा जा रहा है, जिससे आकार में 16 बनाम 4 बाइट होने का नकारात्मक प्रभाव बढ़ जाता है। अधिक बाइट्स का मतलब है डिस्क पर और SQL सर्वर रैम में और अधिक डिस्क I/O और SQL सर्वर के लिए अधिक काम करते हैं।

आप निश्चित रूप से GUID को प्राथमिक कुंजी के रूप में रख सकते हैं, जहां उपयुक्त हो - लेकिन उस स्थिति में, मैं दृढ़ता से उस तालिका में एक अलग पहचान पहचान जोड़ने और क्लस्टरिंग कुंजी बनाने की सलाह देता हूं। मैंने खुद को कई बड़ी तालिकाओं के साथ किया है, और परिणाम आश्चर्यचकित हैं - तालिका विखंडन 99 से नीचे है और अधिक प्रतिशत कुछ प्रतिशत से नीचे है, और प्रदर्शन बहुत बेहतर है।

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!

मार्क