sql - यवस - डेटाबेस अनुक्रमण कैसे काम करता है?




हिंदी में डेटाबेस डिजाइन की प्रक्रिया (6)

यह देखते हुए कि इंडेक्सिंग इतना महत्वपूर्ण है क्योंकि आपका डेटा सेट आकार में बढ़ता है, क्या कोई समझा सकता है कि डेटाबेस-एग्नॉस्टिक स्तर पर इंडेक्सिंग कैसे काम करता है?

किसी फ़ील्ड को अनुक्रमित करने के लिए क्वेरीज़ की जानकारी के लिए, मैं एक डेटाबेस कॉलम को कैसे अनुक्रमित करूँ , इसकी जाँच करें

https://code.i-harness.com


सरल विवरण!

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

उदाहरण: हमारे पास एक डेटाबेस तालिका है, जिसमें User को तीन कॉलम - Name , Age और Address साथ बुलाया जाता है। मान लें कि User तालिका में हजारों पंक्तियाँ हैं।

अब, मान लें कि हम 'जॉन' नाम वाले किसी भी उपयोगकर्ता के सभी विवरणों को खोजने के लिए एक क्वेरी चलाना चाहते हैं। यदि हम निम्नलिखित क्वेरी चलाते हैं:

SELECT * FROM User 
WHERE Name = 'John'

डेटाबेस सॉफ्टवेयर का शाब्दिक अर्थ है कि User तालिका में हर एक पंक्ति को देखना होगा कि क्या उस पंक्ति का Name 'जॉन' है। इसमें लंबा समय लगेगा।

यह वह जगह है जहाँ index हमारी मदद करता है: सूचकांक का उपयोग अनिवार्य रूप से एक तालिका में अभिलेखों / पंक्तियों की संख्या में कटौती करके खोज प्रश्नों को गति देने के लिए किया जाता है जिनकी जांच की जानी चाहिए

कैसे एक सूचकांक बनाने के लिए:

CREATE INDEX name_index
ON User (Name)

index में एक तालिका से स्तंभ मान (जैसे: जॉन) होते हैं, और वे मान एक डेटा संरचना में संग्रहीत होते हैं।

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


अब, मान लें कि हम 'एबीसी' नाम वाले किसी भी कर्मचारी के सभी विवरणों को खोजने के लिए एक क्वेरी चलाना चाहते हैं?

SELECT * FROM Employee 
WHERE Employee_Name = 'Abc'

सूचकांक के बिना क्या होगा?

डेटाबेस सॉफ्टवेयर का शाब्दिक अर्थ कर्मचारी तालिका में हर एक पंक्ति को देखना होगा कि क्या उस पंक्ति के लिए कर्मचारी नाम that एबीसी ’है। और, क्योंकि हम इसके अंदर because एबीसी ’नाम के साथ हर पंक्ति चाहते हैं, हम सिर्फ एक बार देखना बंद नहीं कर सकते हैं क्योंकि हमें एबीसी नाम के साथ सिर्फ एक पंक्ति मिलती है, क्योंकि एबीसी नाम के साथ अन्य पंक्तियां हो सकती हैं। इसलिए, हर पंक्ति को अंतिम पंक्ति तक खोजा जाना चाहिए - जिसका अर्थ है कि इस परिदृश्य में हजारों पंक्तियों की जांच डेटाबेस द्वारा 'एबीसी' नाम से पंक्तियों को खोजने के लिए की जाएगी। इसे ही पूर्ण टेबल स्कैन कहा जाता है

डेटाबेस इंडेक्स प्रदर्शन को कैसे मदद कर सकता है

सूचकांक होने का पूरा बिंदु एक तालिका में रिकॉर्ड / पंक्तियों की संख्या को अनिवार्य रूप से काटकर खोज प्रश्नों को गति देना है, जिनकी जांच करने की आवश्यकता है। एक सूचकांक एक डेटा संरचना (आमतौर पर एक बी-ट्री) है जो एक तालिका में एक विशिष्ट स्तंभ के लिए मूल्यों को संग्रहीत करता है।

बी-ट्रीज़ इंडेक्स कैसे काम करता है?

कारण बी- पेड़ इंडेक्स के लिए सबसे लोकप्रिय डेटा संरचना है, इस तथ्य के कारण है कि वे समय कुशल हैं - क्योंकि लुक-अप, विलोपन और सम्मिलन सभी को लघुगणकीय समय में किया जा सकता है। और, एक और प्रमुख कारण B- पेड़ों का अधिक उपयोग किया जाता है क्योंकि B- ट्री के अंदर संग्रहीत डेटा को सॉर्ट किया जा सकता है। RDBMS आमतौर पर यह निर्धारित करता है कि वास्तव में किस डेटा संरचना का उपयोग किसी इंडेक्स के लिए किया जाता है। लेकिन, कुछ निश्चित RDBMS के साथ कुछ परिदृश्यों में, आप वास्तव में निर्दिष्ट कर सकते हैं कि आप अपने डेटाबेस का उपयोग करते समय किस डेटा संरचना का उपयोग करना चाहते हैं।

हैश टेबल इंडेक्स कैसे काम करता है?

हैश इंडेक्स का उपयोग इसलिए किया जाता है क्योंकि हैश टेबल बेहद कुशल होते हैं जब यह केवल मूल्यों को देखने के लिए आता है। तो, एक स्ट्रिंग की समानता के लिए तुलना करने वाले क्वेरीज़ मानों को बहुत तेज़ी से प्राप्त कर सकते हैं यदि वे हैश इंडेक्स का उपयोग करते हैं।

उदाहरण के लिए, जिस क्वेरी की हमने पहले चर्चा की, वह Employee_Name कॉलम पर बनाए गए हैश इंडेक्स से लाभान्वित हो सकती है। जिस तरह से एक हैश इंडेक्स काम करेगा वह यह है कि कॉलम वैल्यू हैश टेबल में कुंजी होगी और उस कुंजी पर मैप किया गया वास्तविक मूल्य टेबल में मौजूद पंक्ति डेटा का एक संकेतक होगा। चूंकि हैश टेबल मूल रूप से एक साहचर्य सरणी है, इसलिए एक विशिष्ट प्रविष्टि "एबीसी => 0x28939 is की तरह दिखाई देगी, जहां 0x28939 तालिका पंक्ति का संदर्भ है जहां एबीसी मेमोरी में संग्रहीत है। हैश टेबल इंडेक्स में "एबीसी" जैसे मान को देखना और स्मृति में पंक्ति का संदर्भ प्राप्त करना स्पष्ट रूप से कर्मचारी के नाम स्तंभ में "एबीसी" के मूल्य के साथ सभी पंक्तियों को खोजने के लिए तालिका को स्कैन करने की तुलना में बहुत तेज है।

हैश इंडेक्स का नुकसान

हैश टेबल डेटा संरचनाओं को सॉर्ट नहीं किया जाता है, और कई प्रकार के प्रश्न हैं जो हैश इंडेक्स भी मदद नहीं कर सकते हैं। उदाहरण के लिए, मान लीजिए कि आप उन सभी कर्मचारियों का पता लगाना चाहते हैं, जिनकी आयु 40 वर्ष से कम है। आप हैश टेबल इंडेक्स के साथ ऐसा कैसे कर सकते हैं? खैर, यह संभव नहीं है क्योंकि एक हैश टेबल केवल महत्वपूर्ण मूल्य जोड़े को देखने के लिए अच्छा है - जिसका अर्थ है कि समानता के लिए जांच करने वाले प्रश्न

डेटाबेस सूचकांक के अंदर वास्तव में क्या है? तो, अब आप जानते हैं कि एक तालिका में एक स्तंभ पर एक डेटाबेस इंडेक्स बनाया जाता है, और यह कि सूचकांक उस विशिष्ट कॉलम में मूल्यों को संग्रहीत करता है। लेकिन, यह समझना महत्वपूर्ण है कि एक डेटाबेस इंडेक्स मानों को उसी तालिका के अन्य स्तंभों में संग्रहीत नहीं करता है। उदाहरण के लिए, यदि हम Employee_Name कॉलम पर एक इंडेक्स बनाते हैं, तो इसका मतलब है कि Employee_Age और Employee_Address कॉलम मान भी इंडेक्स में संग्रहीत नहीं हैं। यदि हमने इंडेक्स में अन्य सभी कॉलम को स्टोर किया है, तो यह पूरी टेबल की एक और कॉपी बनाने जैसा होगा - जो कि बहुत अधिक जगह ले जाएगा और बहुत ही अकुशल होगा।

सूचकांक का उपयोग करने के लिए एक डेटाबेस को कैसे पता चलता है? जब "चयन करें * कर्मचारी से जहां कर्मचारी ए 'नाम =' एबीसी 'चलाया जाता है, तो डेटाबेस यह देखने के लिए जांच करेगा कि क्या कॉलम (ओं) पर कोई इंडेक्स है या नहीं। Employee_Name कॉलम को मानकर उस पर एक इंडेक्स बनाया गया है, डेटाबेस को यह तय करना होगा कि क्या यह वास्तव में खोजे जा रहे मूल्यों को खोजने के लिए इंडेक्स का उपयोग करने के लिए समझ में आता है - क्योंकि कुछ परिदृश्य हैं जहां यह वास्तव में डेटाबेस इंडेक्स का उपयोग करने के लिए कम कुशल है , और अधिक कुशल बस पूरी मेज को स्कैन करने के लिए।

डेटाबेस इंडेक्स होने की लागत क्या है?

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

एक सामान्य नियम के रूप में, एक इंडेक्स केवल एक टेबल पर बनाया जाना चाहिए, यदि इंडेक्स किए गए कॉलम में डेटा अक्सर क्वियर किया जाएगा।

यह भी देखें

  1. आमतौर पर कौन से कॉलम अच्छे इंडेक्स बनाते हैं?
  2. डेटाबेस इंडेक्स कैसे काम करते हैं

क्लासिक उदाहरण "पुस्तकों में सूचकांक"

1000 पृष्ठों की "पुस्तक" पर विचार करें, 100 खंडों से विभाजित किया गया है, एक्स पृष्ठों के साथ प्रत्येक अनुभाग।

सरल, हुह?

अब, एक इंडेक्स पेज के बिना, एक विशेष खंड को खोजने के लिए जो पत्र "एस" से शुरू होता है, आपके पास पूरी पुस्तक के माध्यम से स्कैन करने के अलावा कोई अन्य विकल्प नहीं है। यानी: 1000 पेज

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

लेकिन फिर, 1000 पृष्ठों के अलावा, आपको अनुक्रमणिका पृष्ठ प्रदर्शित करने के लिए एक और ~ 10 पृष्ठों की आवश्यकता होगी, इसलिए पूरी तरह से 1010 पृष्ठ।

इस प्रकार, सूचकांक एक अलग खंड है जो कुशल लुक-अप के लिए अनुक्रमित क्रम में अनुक्रमित पंक्ति + सूचक के मूल्यों को संग्रहीत करता है।

स्कूलों में चीजें सरल हैं, है ना? : पी


पहली बार जब मैंने इसे पढ़ा तो यह मेरे लिए बहुत उपयोगी था। धन्यवाद।

तब से मैंने इंडेक्स बनाने के नकारात्मक पहलू के बारे में कुछ जानकारी प्राप्त की: यदि आप एक इंडेक्स के साथ एक तालिका ( UPDATE या INSERT ) में लिखते हैं, तो आपके पास फ़ाइल सिस्टम में वास्तव में दो राइटिंग ऑपरेशन हैं। टेबल डेटा के लिए एक और इंडेक्स डेटा के लिए एक और (इसका सहारा लेना (और - अगर क्लस्टर किया - टेबल डेटा का सहारा लेना))। यदि टेबल और इंडेक्स एक ही हार्ड डिस्क पर स्थित हैं, तो यह अधिक समय खर्च करता है। इस प्रकार एक सूचकांक (एक ढेर) के बिना एक मेज, जल्दी से लिखने के संचालन के लिए अनुमति देगा। (यदि आपके पास दो अनुक्रमणिका हैं तो आप तीन लिखने के संचालन के साथ समाप्त हो जाएंगे, और इसी तरह)

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

इंडेक्स के साथ एक और समस्या समय के साथ उनका विखंडन है क्योंकि डेटा डाला जाता है। REORGANIZE मदद करता है, आप इसे करने के लिए दिनचर्या लिखना चाहिए।

कुछ परिदृश्यों में एक ढेर इंडेक्स वाली तालिका की तुलना में अधिक उपयोगी है,

उदाहरण: - यदि आपके पास बहुत से प्रतिद्वंद्वी लिखते हैं, लेकिन रिपोर्टिंग के लिए केवल एक रात के बाहर व्यावसायिक घंटे पढ़ते हैं।

इसके अलावा, गुच्छेदार और गैर-संकुल अनुक्रमणिका के बीच एक अंतर बल्कि महत्वपूर्ण है।

मेरी मदद की: - क्लस्टर्ड और नॉन क्लस्टर्ड इंडेक्स का वास्तव में क्या मतलब है?


बस डेटाबेस इंडेक्स को एक पुस्तक के सूचकांक के रूप में सोचें।

यदि आपके पास कुत्तों के बारे में एक किताब है और आप जर्मन शेफर्ड के बारे में एक जानकारी प्राप्त करना चाहते हैं, तो आप निश्चित रूप से पुस्तक के सभी पृष्ठों के माध्यम से फ्लिप कर सकते हैं और पा सकते हैं कि आप क्या देख रहे हैं - लेकिन यह निश्चित रूप से समय लेने वाली है और नहीं बहुत तेज़।

एक अन्य विकल्प यह है कि, आप बस पुस्तक के इंडेक्स सेक्शन में जा सकते हैं और फिर जो आप देख रहे हैं उसका नाम (इस उदाहरण में, जर्मन शेफर्ड) का उपयोग करके जो आप देख रहे हैं वह भी पा सकते हैं और पृष्ठ संख्या भी देख सकते हैं जल्दी से तुम क्या देख रहे हो।

डेटाबेस में, पृष्ठ संख्या को एक पॉइंटर के रूप में संदर्भित किया जाता है जो डेटाबेस को उस डिस्क पर पते पर निर्देशित करता है जहां इकाई स्थित है। उसी जर्मन शेफर्ड सादृश्य का उपयोग करते हुए, हम कुछ इस तरह से हो सकते हैं ("जर्मन शेफर्ड", 0x77129) जहां 0x77129 डिस्क पर पता है जहां जर्मन शेफर्ड के लिए पंक्ति डेटा संग्रहीत है।

संक्षेप में, एक सूचकांक एक डेटा संरचना है जो एक विशिष्ट स्तंभ के लिए मानों को संग्रहीत करता है ताकि क्वेरी खोज को गति दी जा सके।


इसकी आवश्यकता क्यों है?

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

इस तथ्य के कारण कि कई रिकॉर्ड केवल एक फ़ील्ड पर सॉर्ट किए जा सकते हैं, हम यह बता सकते हैं कि सॉर्ट किए गए फ़ील्ड पर खोज करने के लिए एक रैखिक खोज की आवश्यकता होती है जिसमें N/2 ब्लॉक एक्सेस की आवश्यकता होती है (औसतन), जहां N है ब्लॉक की संख्या जो तालिका में फैली हुई है। यदि वह फ़ील्ड एक गैर-कुंजी फ़ील्ड है (अर्थात जिसमें अद्वितीय प्रविष्टियाँ नहीं हैं) तो पूरे ब्लॉकस्पेस को N ब्लॉक एक्सेस पर खोजना होगा।

जबकि एक सॉर्ट किए गए फ़ील्ड के साथ, एक बाइनरी खोज का उपयोग किया जा सकता है, जिसमें log2 N ब्लॉक एक्सेस है। चूंकि डेटा को एक गैर-कुंजी फ़ील्ड दिया जाता है, इसलिए बाकी तालिका को एक बार उच्च मान मिलने पर, डुप्लिकेट मानों के लिए खोज करने की आवश्यकता नहीं होती है। इस प्रकार प्रदर्शन में वृद्धि पर्याप्त है।

अनुक्रमण क्या है?

अनुक्रमण कई क्षेत्रों पर कई रिकॉर्ड को सॉर्ट करने का एक तरीका है। किसी तालिका में एक फ़ील्ड पर एक इंडेक्स बनाने से एक और डेटा संरचना बनती है जो फ़ील्ड मान रखती है, और रिकॉर्ड के लिए एक पॉइंटर जो इससे संबंधित है। इस सूचकांक संरचना को तब क्रमबद्ध किया जाता है, जिससे बाइनरी खोजों को उस पर प्रदर्शन करने की अनुमति मिलती है।

अनुक्रमण के लिए नकारात्मक पक्ष यह है कि इन सूचकांकों को डिस्क पर अतिरिक्त स्थान की आवश्यकता होती है क्योंकि सूचकांकों को MyISAM इंजन का उपयोग करके तालिका में एक साथ संग्रहीत किया जाता है, यह फ़ाइल अंतर्निहित फ़ाइल सिस्टम की आकार सीमा तक जल्दी से पहुँच सकती है यदि एक ही तालिका के भीतर कई फ़ील्ड्स अनुक्रमणित किए गए हों ।

यह कैसे काम करता है?

सबसे पहले, चलो एक नमूना डेटाबेस तालिका स्कीमा की रूपरेखा तैयार करते हैं;

Field name       Data type      Size on disk
id (Primary key) Unsigned INT   4 bytes
firstName        Char(50)       50 bytes
lastName         Char(50)       50 bytes
emailAddress     Char(100)      100 bytes

नोट : चर का उपयोग varchar के स्थान पर डिस्क मान पर सटीक आकार की अनुमति देने के लिए किया गया था। इस सैंपल डेटाबेस में पाँच मिलियन पंक्तियाँ हैं और यह अनइंडैक्स है। कई प्रश्नों के प्रदर्शन का अब विश्लेषण किया जाएगा। ये आईडी (एक सॉर्ट किए गए कुंजी फ़ील्ड) का उपयोग करके एक क्वेरी है और पहले नाम (एक गैर-कुंजी रहित फ़ील्ड) का उपयोग कर रहे हैं।

उदाहरण 1 - छंटे हुए बनाम अनसुलझे खेत

R = 204 बाइट्स की रिकॉर्ड लंबाई देने वाले निश्चित आकार के r = 5,000,000 रिकॉर्ड के हमारे सैंपल डेटाबेस को देखते हुए और उन्हें MyISAM इंजन का उपयोग करके एक तालिका में संग्रहीत किया जाता है जो डिफ़ॉल्ट ब्लॉक आकार B = 1,024 बाइट्स का उपयोग कर रहा है। तालिका का अवरोधक कारक bfr = (B/R) = 1024/204 = 5 रिकॉर्ड प्रति डिस्क ब्लॉक होगा। तालिका रखने के लिए आवश्यक ब्लॉकों की कुल संख्या N = (r/bfr) = 5000000/5 = 1,000,000 ब्लॉक है।

आईडी फ़ील्ड पर एक रेखीय खोज के लिए एक मान खोजने के लिए औसतन N/2 = 500,000 ब्लॉक एक्सेस की आवश्यकता होगी, यह देखते हुए कि आईडी फ़ील्ड एक महत्वपूर्ण फ़ील्ड है। लेकिन चूंकि आईडी फ़ील्ड को भी सॉर्ट किया गया है, इसलिए log2 1000000 = 19.93 = 20 ब्लॉक एक्सेस की आवश्यकता के लिए एक बाइनरी खोज आयोजित की जा सकती है। तुरंत हम देख सकते हैं कि यह एक व्यापक सुधार है।

अब FirstName फ़ील्ड को न तो सॉर्ट किया गया है और न ही कोई कुंजी फ़ील्ड है, इसलिए बाइनरी खोज असंभव है, और न ही मान विशिष्ट हैं, और इस प्रकार तालिका को सटीक N = 1,000,000 ब्लॉक एक्सेस के लिए अंत की खोज करने की आवश्यकता होगी। यह स्थिति है कि अनुक्रमण का उद्देश्य सही करना है।

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

Field name       Data type      Size on disk
firstName        Char(50)       50 bytes
(record pointer) Special        4 bytes

नोट : MySQL में पॉइंटर्स तालिका के आकार के आधार पर लंबाई में 2, 3, 4 या 5 बाइट्स हैं।

उदाहरण 2 - अनुक्रमण

R = 54 बाइट्स के इंडेक्स रिकॉर्ड लंबाई के साथ r = 5,000,000 रिकॉर्ड के हमारे नमूना डेटाबेस को देखते हुए और डिफ़ॉल्ट ब्लॉक आकार B = 1,024 बाइट्स का उपयोग करके। सूचकांक का अवरोधक कारक bfr = (B/R) = 1024/54 = 18 प्रति डिस्क ब्लॉक होगा। सूचकांक रखने के लिए आवश्यक ब्लॉक की कुल संख्या N = (r/bfr) = 5000000/18 = 277,778 ब्लॉक है।

अब FirstName फ़ील्ड का उपयोग करके खोज प्रदर्शन बढ़ाने के लिए सूचकांक का उपयोग कर सकती है। यह log2 277778 = 18.08 = 19 ब्लॉक एक्सेस के औसत के साथ सूचकांक की एक द्विआधारी खोज की अनुमति देता है। वास्तविक रिकॉर्ड का पता खोजने के लिए, जिसे पढ़ने के लिए आगे ब्लॉक एक्सेस की आवश्यकता होती है, कुल 19 + 1 = 20 ब्लॉक एक्सेस को लाने के लिए, गैर-अनुक्रमित तालिका में पहला नाम मैच खोजने के लिए आवश्यक 1,000,000 ब्लॉक एक्सेस से बहुत दूर रोना पड़ता है।

इसका उपयोग कब किया जाना चाहिए?

यह देखते हुए कि एक इंडेक्स बनाने के लिए अतिरिक्त डिस्क स्थान की आवश्यकता होती है (उपरोक्त उदाहरण से अतिरिक्त 277,778 ब्लॉक, एक ~ 28% वृद्धि), और वह भी बहुत से सूचकांकों के कारण फाइल सिस्टम के आकार की सीमा से उत्पन्न होने वाले मुद्दे पैदा हो सकते हैं, सही का चयन करने के लिए सावधानीपूर्वक सोचा जाना चाहिए। क्षेत्रों को अनुक्रमणित करें।

चूंकि सूचकांकों का उपयोग केवल रिकॉर्ड के भीतर एक मेल खाने वाले क्षेत्र की खोज में तेजी लाने के लिए किया जाता है, यह इस कारण से होता है कि आउटपुट के लिए उपयोग किए जाने वाले अनुक्रमण फ़ील्ड केवल डिस्क स्थान और प्रसंस्करण समय की बर्बादी होगी जब एक सम्मिलित या ऑपरेशन हटाएं, और इस तरह। से बचा जाना चाहिए। एक द्विआधारी खोज की प्रकृति को देखते हुए, डेटा की कार्डिनैलिटी या विशिष्टता महत्वपूर्ण है। 2 की कार्डिनैलिटी के साथ एक फ़ील्ड पर अनुक्रमित करने से डेटा आधे में विभाजित हो जाएगा, जबकि 1,000 की कार्डिनैलिटी लगभग 1,000 रिकॉर्ड लौटाएगी। इस तरह की कम कार्डिनैलिटी के साथ प्रभावशीलता एक रैखिक प्रकार तक कम हो जाती है, और क्वेरी ऑप्टिमाइज़र इंडेक्स का उपयोग करने से बचेंगे यदि कार्डिनैलिटी रिकॉर्ड संख्या का 30% से कम है, तो प्रभावी रूप से इंडेक्स को अंतरिक्ष की बर्बादी बना देता है।






database-indexes