क्लस्टर्ड इंडेक्स को किस कॉलम पर रखा जाना चाहिए?

Question

हाल ही में, मैं सभी प्रकार के सूचकांक पर कुछ पढ़ रहा हूं और मुख्य सलाह क्लस्टर इंडेक्स को तालिका की प्राथमिक कुंजी पर रखना है, लेकिन यदि प्राथमिक कुंजी वास्तव में किसी क्वेरी में उपयोग नहीं की जाती है (चयन के माध्यम से या शामिल हों) और केवल विशुद्ध रूप से संबंधपरक उद्देश्यों के लिए रखा गया है, इसलिए इस मामले में इसके खिलाफ पूछताछ नहीं की गई है। उदाहरण के लिए, मेरे पास car_parts तालिका है और इसमें 3 कॉलम, car_part_id, car_part_no, और car_part_title शामिल हैं। car_part_id अद्वितीय प्राथमिक कुंजी पहचान कॉलम है। इस मामले में car_part_no अद्वितीय भी है और सबसे अधिक संभावना car_part_title है। car_part_no इसके खिलाफ सबसे अधिक पूछताछ की गई है, तो क्या car_part_id की बजाय क्लस्टर इंडेक्स को उस कॉलम पर रखना समझ में नहीं आता है? प्रश्न की मूल बातें यह है कि कॉलम में वास्तव में क्लस्टर इंडेक्स होना चाहिए क्योंकि आपको केवल उनमें से एक की अनुमति है?

Answer 1

एक सूचकांक, क्लस्टर या गैर क्लस्टर, क्वेरी ऑप्टिमाइज़र द्वारा उपयोग किया जा सकता है यदि केवल और अगर सूचकांक में बाएं कुंजी कुंजी फ़िल्टर की जाती है। इसलिए यदि आप B=@b पर पर B=@b AND C=@c पर एक WHERE स्थिति को कॉलम (ए, बी, सी) पर एक इंडेक्स परिभाषित करते हैं, तो सूचकांक (नोट देखें) पूरी तरह से लाभ नहीं उठाएगा। यह स्थितियों में शामिल होने के लिए भी लागू होता है।A में कोई भी फ़िल्टर फ़िल्टर सूचकांक पर विचार करेगा: A=@a या A=@a AND B=@b या A=@a AND C=@c या A=@a AND B=@b AND C=@c।

तो अपने उदाहरण में आप part_no पर clustred सूचकांक बनाने यदि वाम-पंथी कुंजी के रूप में, तो एक प्रश्न एक विशिष्ट part_id की तलाश में सूचकांक और एक अलग गैर क्लस्टर सूचकांक part-id पर मौजूद होना चाहिए का उपयोग नहीं होगा।

अब सवाल के बारे में कई इंडेक्स क्लस्टर एक होना चाहिए। आप कई क्वेरी पैटर्न है कि एक ही महत्व और आवृत्ति के बारे में कर रहे हैं और जरूरत कुंजी के मामले पर एक-दूसरे का खंडन किया है (जैसे द्वारा लगातार प्रश्नों या तोpart_no या part_id।) तो आप को ध्यान में अन्य कारकों ले:

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

नोट: नहीं पूरी तरह से लाभ उठाने के रूप में कभी कभी इंजन एक गैर क्लस्टर सूचकांक स्कैन बजाय संकुल सूचकांक करने के लिए चयन करेंगे क्योंकि संकरा है और इस तरह स्कैन करने के लिए कम पृष्ठों है। मेरे उदाहरण में यदि आपके पास B=@b पर एक WHERE फ़िल्टर है और क्वेरी प्रोजेक्ट C पर प्रोजेक्ट है, तो इंडेक्स का उपयोग संभवतः स्कैन के रूप में नहीं किया जाएगा, क्योंकि एक स्कैन के रूप में, अभी भी तेज है पूर्ण क्लस्टर स्कैन (कम पेज)।

Answer 2

क्लस्टर सूचकांक को कॉलम पर जाना चाहिए जो सबसे अधिक पूछताछ की जाएगी। इसमें जॉइन शामिल हैं, क्योंकि एक जॉइन को सीधे क्वेरी की तरह टेबल तक पहुंचना होगा, और पंक्तियों को इंगित करना होगा।

यदि आपका एप्लिकेशन बदलता है तो आप हमेशा बाद में अपने इंडेक्स का पुनर्निर्माण कर सकते हैं और आपको लगता है कि आपको एक अलग इंडेक्स संरचना के साथ एक टेबल को अनुकूलित करने की आवश्यकता है।

आपकी तालिका को क्लस्टर करने के तरीके पर निर्णय लेने के लिए कुछ अतिरिक्त दिशानिर्देश यहां एमएसडीएन पर पाए जा सकते हैं: Clustered Index Design Guidelines।

Answer 3

उपयोग पैटर्न को ध्यान में रखें; यदि आप लगभग हमेशा car_part_no पर डीबी से पूछताछ कर रहे हैं, तो शायद उस कॉलम पर क्लस्टर होने के लिए यह फायदेमंद होगा।

हालांकि, शामिल होने के बारे में मत भूलना; यदि आप अक्सर तालिका में शामिल होते हैं और जॉइन car_part_id फ़ील्ड का उपयोग करता है, तो आपके पास क्लस्टर को car_part_id पर रखने का एक अच्छा कारण है।

कुछ और ध्यान में रखने के लिए कुछ और (इस मामले में कम, लेकिन आम तौर पर क्लस्टर इंडेक्स पर विचार करते समय) यह है कि क्लस्टर्ड इंडेक्स तालिका पर हर दूसरे इंडेक्स में स्पष्ट रूप से दिखाई देगा; तो उदाहरण के लिए, यदि आप car_part_title को इंडेक्स करना चाहते हैं, तो उस इंडेक्स में car_part_id भी शामिल होगा। यह प्रभावित कर सकता है कि कोई अनुक्रमणिका किसी क्वेरी को कवर करती है या नहीं और यह भी प्रभावित करती है कि इंडेक्स कितनी डिस्क स्पेस लेगा (जो मेमोरी उपयोग को प्रभावित करता है)।

Answer 4

क्लस्टरर्ड इंडेक्स अच्छे होते हैं जब आप डेटा की श्रृंखला पूछते हैं। उदाहरण के लिए

SELECT * FROM theTable WHERE age BETWEEN 10 AND 20 

क्लस्टर सूचकांक आपके कंप्यूटर डिस्क पर विशेष क्रम में पंक्तियों की व्यवस्था करता है। यही कारण है कि उम्र = 10 के साथ पंक्तियों एक दूसरे के बगल हो जाएगा, और उनके बाद वहाँ, उम्र = 11 के साथ पंक्तियों हो जाएगा आदि

आप सटीक चयन किया है, तो इस तरह:

SELECT * FROM theTable WHERE age = 20 

गैर -क्स्टर्ड सूचकांक भी अच्छा है। यह आपके कंप्यूटर डिस्क पर डेटा पुनर्व्यवस्थित नहीं करता है, लेकिन यह आपको आवश्यक पंक्तियों के पॉइंटर्स के साथ विशेष पेड़ बनाता है।

तो यह आपके द्वारा किए जाने वाले प्रश्नों के प्रकार पर दृढ़ता से निर्भर करता है।

Answer 5

किम्बर्ली ट्रिप इंडेक्सिंग पर अंतर्दृष्टि पर हमेशा सर्वोत्तम स्रोतों में से एक है।

उसके ब्लॉग पोस्ट "Ever-increasing clustering key - the Clustered Index Debate - again!" जिसमें वह काफी स्पष्ट रूप सूचीबद्ध करता है और एक अच्छा क्लस्टरिंग कुंजी के लिए मुख्य आवश्यकताओं बताते देखें - यह होने की जरूरत है:

• अनोखा
• संकीर्ण
• स्टेटिक

और सभी का सबसे अच्छा, आप का प्रबंधन कर सकते हैं:

• बढ़ती

खाते में यह सब ले रहा है, एक INT IDENTITY (या BIGINT IDENTITY तुम सच में 2 बिलियन से अधिक पंक्तियों की जरूरत है) बाहर काम करता है अधिकांश मामलों में सबसे अच्छा विकल्प हो सकता है।

एक बात यह है कि बहुत से लोगों को एहसास नहीं होता है (और इस प्रकार उनकी पसंद करते समय ध्यान में नहीं आता) यह तथ्य है कि क्लस्टरिंग कुंजी (क्लस्टर इंडेक्स बनाने वाले सभी कॉलम) में जोड़ा जाएगा आपकी तालिका पर प्रत्येक और गैर-क्लस्टर सूचकांक के लिए प्रत्येक सूचकांक प्रविष्टि - इस प्रकार "संकीर्ण" आवश्यकता अतिरिक्त महत्वपूर्ण हो जाती है!

इसके अलावा, क्लस्टरिंग कुंजी का उपयोग बुकमार्क लुकअप के लिए किया जाता है (जब कोई पंक्ति गैर-क्लस्टर इंडेक्स में होती है तो वास्तविक डेटा पंक्ति को देखकर), "अद्वितीय" आवश्यकता भी बहुत महत्वपूर्ण हो जाती है। वास्तव में, यह महत्वपूर्ण है कि यदि आप एक (सेट) कॉलम (एस) चुनते हैं जो अद्वितीय होने की गारंटी नहीं है, तो SQL सर्वर प्रत्येक पंक्ति में 4-बाइट अनन्यफियर जोड़ देगा -> इस प्रकार आप में से प्रत्येक को बनाना क्लस्टर सूचकांक कुंजी अतिरिक्त चौड़ा; निश्चित रूप से एक अच्छी बात नहीं है।

मार्क