यदि आपके पास प्राथमिक कुंजी (int) पर क्लस्टर्ड इंडेक्स वाली तालिका है, तो क्या यह अनावश्यक और खराब है (एक और अधिक) गैर क्लस्टर इंडेक्स जिसमें गैर-कॉलम में कॉलम में से एक के रूप में प्राथमिक कुंजी कॉलम शामिल है, क्लस्टर सूचकांक?क्या यह गैर-क्लस्टर्ड इंडेक्स होना बुरा है जिसमें क्लस्टर्ड इंडेक्स से प्राथमिक कुंजी है?
असल में वहाँ वैध कारण एक गैर क्लस्टर सूचकांक समान संकुल एक साथ बनाने के लिए हो सकता है। कारण यह है कि क्लस्टर्ड इंडेक्स पंक्ति डेटा के सामान लेते हैं और इससे बहुत खराब पंक्ति घनत्व हो सकता है। अर्थात। आपके पास क्लस्टर कुंजी में नहीं होने वाले विस्तृत फ़ील्ड के कारण प्रति पृष्ठ 2-3 पंक्तियां हो सकती हैं, लेकिन क्लस्टरर्ड इंडेक्स कुंजी केवल 20 बाइट्स कहती है। पर एक गैर-क्लस्टर इंडेक्स होने पर बिल्कुल समान कुंजी और क्रम के रूप में क्लस्टरर्ड इंडेक्स 2-3 सैकड़ों प्रति पृष्ठ कुंजी का घनत्व प्रदान करेगा। ओलाप/बीआई वर्कलोड के लिए सामान्य रूप से बहुत सारे प्रश्नों का उत्तर गैर-क्लस्टर इंडेक्स द्वारा अधिक कुशलता से दिया जा सकता है, क्योंकि यह सैकड़ों बार I/O को कम करता है।
क्लस्टर कुंजी के हिस्सों, या यहां तक कि एक ही कुंजी के अलावा गैर-क्लस्टर इंडेक्स के लिए, लेकिन अलग-अलग क्रम में, तो सभी दांव बंद हैं क्योंकि स्पष्ट रूप से कई प्रश्नों के लिए उपयोग किया जा सकता है।
तो आपके प्रश्न का उत्तर यह है: यह पर निर्भर करता है।
अधिक सटीक उत्तर के लिए आपको अपनी तालिका (ओं) की सटीक स्कीमा और शामिल सटीक प्रश्नों को साझा करना होगा।
कोई 100% उत्तर नहीं है, लेकिन उत्तर लगभग निश्चित रूप से है।
अन्य अनुक्रमणिका वहां शामिल होने और सॉर्टिंग (आमतौर पर) में सहायता करने में सहायता करने के लिए हैं। यह देखते हुए कि प्राथमिक कुंजी पहले से ही अनुक्रमित है, अगर अनुकूलक उस पर आधारित हो सकता है तो इसका उपयोग करेगा।
यदि किसी अन्य इंडेक्स को शामिल/सॉर्ट परिप्रेक्ष्य से आवश्यक है, तो इंडेक्स मिश्रण में पीके को अतिरिक्त सहायता क्या है? अगर यह पहले पीके के आधार पर शामिल नहीं हो सका, तो यह अभी नहीं जा रहा है। और यह वास्तव में किसी भी क्रमबद्ध करने में मदद करने के लिए नहीं जा रहा है।
हां, यह आम तौर पर आवश्यक नहीं है, क्योंकि क्लस्टर्ड इंडेक्स के कॉलम पहले से ही गैर-क्लस्टर इंडेक्स में प्रत्येक इंडेक्स एंट्री में जोड़े जाते हैं।
क्यों? क्लस्टर कुंजी का मान वास्तव में SQL सर्वर को डेटा की एक पंक्ति "ढूंढने" की अनुमति देता है - यह वास्तविक डेटा के लिए "पॉइंटर" है - इसलिए obviuosly, इसे गैर-क्लस्टर इंडेक्स में संग्रहीत किया जाना है। यदि आपने "स्मिथ, जॉन" को देखा है और आपको इस व्यक्ति के बारे में और जानने की जरूरत है, तो आपको वास्तविक डेटा -> पर जाना होगा और यह गैर-सूचकांक के इंडेक्स नोड में क्लस्टरिंग कुंजी के मूल्य को शामिल करके किया जाता है। क्लस्टर सूचकांक।
वह क्लस्टर कुंजी मान पहले से मौजूद है, और इस प्रकार आम तौर पर यह गैर-क्लस्टर सूचकांक के लिए उस मूल्य को फिर से जोड़ने के लिए अनावश्यक और अनावश्यक है। यह बुरा है कि यह आपको बिना किसी लाभ के बस अंतरिक्ष को बर्बाद कर देता है।
मैं इस पर रीमस के साथ हूं - एक क्लस्टर सूचकांक वास्तव में एक सूचकांक नहीं है - यह आपको बताता है कि पृष्ठों में डेटा कैसे व्यवस्थित किया जाता है। (आपके मामले में, यह प्राथमिक कुंजी भी है, लेकिन यह एक ही चीज़ होने की आवश्यकता नहीं है)। गैर क्लस्टर इंडेक्स में उस पंक्ति लोकेटर की जानकारी शामिल है, इसलिए हाँ, यह अनावश्यक है।
लेकिन अगर एक गैर क्लस्टर सूचकांक और डेटा पंक्ति बुकमार्क इस्तेमाल किया जा की जरूरत नहीं है को कवर किया जाता है, यह एक बहुत अधिक कुशलता से क्लस्टर सूचकांक, और दक्षता इस्तेमाल किया जा सकता गैर-क्लस्टर इंडेक्स के आकार में डेटा पंक्ति के आकार के अनुपात के अनुपात के रूप में बढ़ता है।
मुझे पता चला है कि यदि आपके प्रश्न वर्कलोड में पहुंच पथों पर एक अच्छा संभाल है, तो कभी-कभी गैर-क्लस्टर्ड इंडेक्स को चुनने वाले कुछ चुनिंदा क्लस्टरिंग विकल्पों को पूरी तरह से खत्म करने के लिए उपयोग किया जा सकता है - हीप टेबल, एक पीके, और कुछ अच्छी गैर-क्लस्टर इंडेक्स, और आप कर चुके हैं।