SQL सर्वर MVP ब्रैड मैकगी की तुलना में इसे अधिक संक्षेप में बताना कठिन है:
<ब्लॉकक्वॉट>एक नियम के रूप में, प्रत्येक तालिका में एक संकुल अनुक्रमणिका होनी चाहिए। आम तौर पर, लेकिन हमेशा नहीं, क्लस्टर इंडेक्स एक ऐसे कॉलम पर होना चाहिए जो एकरस रूप से बढ़ता है - जैसे कि एक पहचान कॉलम, या कोई अन्य कॉलम जहां मान बढ़ रहा है - और अद्वितीय है। कई मामलों में, प्राथमिक कुंजी क्लस्टर इंडेक्स के लिए आदर्श कॉलम होती है।
बीओएल इस भावना को प्रतिध्वनित करता है:
<ब्लॉकक्वॉट>कुछ अपवादों के साथ, प्रत्येक तालिका में एक संकुल अनुक्रमणिका होनी चाहिए।
ऐसा करने के कई कारण हैं और प्राथमिक रूप से इस तथ्य पर आधारित हैं कि एक संकुल अनुक्रमणिका आपके डेटा को संग्रहण में भौतिक रूप से ऑर्डर करती है ।
-
अगर आपका क्लस्टर इंडेक्स एक ही कॉलम पर है, तो एकरसता से वृद्धि होती है, आपके स्टोरेज डिवाइस पर इंसर्ट्स क्रम में होते हैं और पेज स्प्लिट नहीं होंगे।
-
जब अनुक्रमित मान अद्वितीय होता है, जैसे प्राथमिक कुंजी के आधार पर एक पंक्ति का चयन करने का सामान्य पैटर्न, क्लस्टर्ड इंडेक्स एक विशिष्ट पंक्ति को खोजने के लिए कुशल होते हैं।
-
क्लस्टर्ड इंडेक्स अक्सर उन स्तंभों पर कुशल प्रश्नों की अनुमति देता है जिन्हें अक्सर मानों की श्रेणियों के लिए खोजा जाता है (
between,>, आदि)। -
क्लस्टरिंग उन प्रश्नों को गति दे सकता है जहां डेटा को आमतौर पर एक विशिष्ट कॉलम या कॉलम द्वारा क्रमबद्ध किया जाता है।
-
तालिका विखंडन को नियंत्रित करने की मांग पर एक संकुल सूचकांक को फिर से बनाया या पुनर्गठित किया जा सकता है।
-
इन लाभों को विचारों पर भी लागू किया जा सकता है।
हो सकता है कि आप इस पर संकुल अनुक्रमणिका नहीं रखना चाहें:
-
जिन स्तंभों में बार-बार डेटा परिवर्तन होता है, क्योंकि SQL सर्वर को डेटा को भंडारण में भौतिक रूप से पुन:व्यवस्थित करना चाहिए।
-
कॉलम जो पहले से ही अन्य इंडेक्स द्वारा कवर किए गए हैं।
-
वाइड कुंजियाँ, क्योंकि संकुल अनुक्रमणिका का उपयोग गैर-संकुल अनुक्रमणिका लुकअप में भी किया जाता है।
-
GUID कॉलम, जो पहचान से बड़े हैं और प्रभावी रूप से यादृच्छिक मान भी हैं (सॉर्ट किए जाने की संभावना नहीं है), हालांकि
newsequentialid()सम्मिलित करने के दौरान भौतिक पुनर्क्रमण को कम करने में सहायता के लिए इस्तेमाल किया जा सकता है। -
एक ढेर (एक संकुल अनुक्रमणिका के बिना तालिका) का उपयोग करने का एक दुर्लभ कारण यह है कि यदि डेटा को हमेशा गैर-संकुल अनुक्रमणिका के माध्यम से एक्सेस किया जाता है और RID (SQL सर्वर आंतरिक पंक्ति पहचानकर्ता) को क्लस्टर अनुक्रमणिका कुंजी से छोटा माना जाता है।
इन और अन्य विचारों के कारण, जैसे कि आपके विशेष एप्लिकेशन वर्कलोड, आपको अपने प्रश्नों के लिए अधिकतम लाभ प्राप्त करने के लिए सावधानीपूर्वक अपने क्लस्टर इंडेक्स का चयन करना चाहिए।
यह भी ध्यान दें कि जब आप SQL सर्वर में किसी तालिका पर प्राथमिक कुंजी बनाते हैं, तो यह डिफ़ॉल्ट रूप से एक अद्वितीय क्लस्टर अनुक्रमणिका बनाएगी (यदि उसके पास पहले से एक नहीं है)। इसका मतलब यह है कि यदि आपको कोई तालिका मिलती है जिसमें क्लस्टर इंडेक्स नहीं है, लेकिन प्राथमिक कुंजी है (जैसा कि सभी तालिकाओं को होना चाहिए), एक डेवलपर ने पहले इसे इस तरह बनाने का निर्णय लिया था। आप इसे बदलने के लिए एक सम्मोहक कारण रखना चाह सकते हैं (जिनमें से कई हैं, जैसा कि हमने देखा है)। संकलित अनुक्रमणिका को जोड़ने, बदलने या छोड़ने के लिए संपूर्ण तालिका को फिर से लिखना आवश्यक है और कोई भी गैर-संकुल अनुक्रमणिका, इसलिए इसमें एक बड़ी तालिका में कुछ समय लग सकता है।
