कितने डेटाबेस इंडेक्स बहुत अधिक हैं?

Question

मैं एक बड़े ओरेकल डेटाबेस के साथ एक परियोजना पर काम कर रहा हूं (हालांकि मेरा सवाल अन्य डेटाबेस पर भी समान रूप से लागू होता है)। हमारे पास एक वेब इंटरफ़ेस है जो उपयोगकर्ताओं को लगभग किसी भी संभावित क्षेत्रों के संयोजन पर खोज करने की अनुमति देता है।

इन खोजों को तेज़ी से आगे बढ़ाने के लिए, हम अनुक्रमित फ़ील्ड्स और फ़ील्ड्स के संयोजन को जोड़ रहे हैं, जिस पर हमें विश्वास है कि उपयोगकर्ता आमतौर पर खोज करेंगे। हालाँकि, चूंकि हम वास्तव में नहीं जानते हैं कि हमारे ग्राहक इस सॉफ़्टवेयर का उपयोग कैसे करेंगे, इसलिए यह बताना मुश्किल है कि कौन सा इंडेक्स बनाना है।

अंतरिक्ष एक चिंता का विषय नहीं है; हमारे पास एक 4 टेराबाइट RAID ड्राइव है जिसमें से हम केवल एक छोटे से अंश का उपयोग कर रहे हैं। हालांकि, मैं बहुत अधिक अनुक्रमित होने के संभावित प्रदर्शन दंड के बारे में चिंतित हूं। क्योंकि उन अनुक्रमित को हर बार एक पंक्ति में जोड़ने, हटाने, या संशोधित करने की आवश्यकता होती है, मुझे लगता है कि यह एक एकल तालिका पर दर्जनों अनुक्रमित होने के लिए एक बुरा विचार होगा।

तो कितने इंडेक्स को बहुत अधिक माना जाता है? 10? 25? 50? या क्या मुझे वास्तव में, वास्तव में सामान्य और स्पष्ट मामलों को कवर करना चाहिए और बाकी सभी चीजों को अनदेखा करना चाहिए?

Answer 1

यह मेज पर होने वाले संचालन पर निर्भर करता है।

यदि बहुत सारे चयन और बहुत कम बदलाव हैं, तो आप सभी को अनुक्रमित करें .... ये (संभावित) चयन बयानों को गति देंगे।

यदि तालिका UPDATEs, INSERTs + DELETEs द्वारा अत्यधिक हिट की जाती है ... ये बहुत सारे इंडेक्स के साथ बहुत धीमी होगी क्योंकि इन सभी को संशोधित करने की आवश्यकता होती है जब इनमें से कोई एक ऑपरेशन होता है

ऐसा कहने के बाद, आप स्पष्ट रूप से बहुत सारे व्यर्थ इंडेक्स को एक तालिका में जोड़ सकते हैं जो कुछ भी नहीं करेगा। 2 अलग-अलग मान वाले कॉलम में B- ट्री इंडेक्स जोड़ना व्यर्थ होगा क्योंकि यह डेटा को देखने के मामले में कुछ भी नहीं जोड़ता है। एक कॉलम में जितने अधिक मूल्य होंगे, उतना ही यह एक इंडेक्स से लाभान्वित होगा।

Comments

बस स्पष्ट करने के लिए, 2 मानों पर सूचकांक विशिष्ट मामले में व्यर्थ नहीं हो सकता है, जब एक मूल्य शायद ही कभी होता है और आप इसे देखना चाहते हैं। इसलिए यह नहीं है कि मूल्य कितने अनूठे हैं, इसके बारे में कि सूचकांक कितना चयनात्मक है।

— चार्ली_प्ल

Answer 2

मैं आमतौर पर इसी तरह आगे बढ़ता हूं।

1. किसी विशिष्ट दिन डेटा पर चलने वाले वास्तविक प्रश्नों का एक लॉग प्राप्त करें ।
2. अनुक्रमणिका को जोड़ें ताकि सबसे महत्वपूर्ण प्रश्न अनुक्रमणिका को उनकी निष्पादन योजना में हिट करें।
3. उन क्षेत्रों को अनुक्रमित करने से बचने की कोशिश करें जिनमें बहुत सारे अपडेट या आवेषण हैं
4. कुछ इंडेक्स के बाद, एक नया लॉग प्राप्त करें और दोहराएं।

सभी किसी भी अनुकूलन के साथ, मैं अनुरोध किए गए प्रदर्शन तक पहुंचने पर रोक देता हूं (इसका स्पष्ट अर्थ है कि बिंदु 0. विशिष्ट प्रदर्शन आवश्यकताओं को प्राप्त कर रहा होगा)।

Answer 3

बाकी सभी लोग आपको बहुत सलाह दे रहे हैं। आपके आगे बढ़ने पर मेरे पास एक जोड़ा सुझाव है। कुछ बिंदु पर आपको अपनी सर्वश्रेष्ठ अनुक्रमण रणनीति के अनुसार निर्णय लेना होगा। हालांकि, अंत में, सबसे बेहतर प्लानिंग इंडेक्सिंग रणनीति अभी भी उन इंडेक्स का निर्माण कर सकती है जो अंत में उपयोग नहीं हो रहे हैं। एक रणनीति जो आपको इंडेक्स का उपयोग करने देती है जो इंडेक्स के उपयोग की निगरानी करने के लिए उपयोग नहीं की जाती है। आप इस प्रकार है: -

alter index my_index_name monitoring usage;

आप तब मॉनिटर कर सकते हैं कि v $ $ object_usage को क्वेरी करके इंडेक्स का उपयोग किया गया है या नहीं। इस पर जानकारी Oracle® डेटाबेस प्रशासक गाइड में पाई जा सकती है ।

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

Answer 4

डेटा वेयरहाउसिंग में उच्च संख्या में अनुक्रमित होना बहुत आम है। मैंने दो सौ स्तंभों वाले तथ्य तालिकाओं के साथ काम किया है और उनमें से 190 अनुक्रमित हैं।

यद्यपि इस पर एक उपरि है, यह इस संदर्भ में समझा जाना चाहिए कि एक डेटा वेयरहाउस में हम आम तौर पर केवल एक बार एक पंक्ति सम्मिलित करते हैं, हम इसे कभी भी अपडेट नहीं करते हैं, लेकिन यह हजारों चुनिंदा प्रश्नों में भाग ले सकता है जो किसी भी अनुक्रमणिका से लाभान्वित हो सकते हैं कॉलम।

अधिकतम लचीलेपन के लिए एक डेटा वेयरहाउस आमतौर पर उच्च कार्डिनलिटी कॉलम को छोड़कर सिंगल कॉलम बिटमैप इंडेक्स का उपयोग करता है, जहां (संपीड़ित) बीटीआरई इंडेक्स का उपयोग किया जा सकता है।

सूचकांक रखरखाव पर ओवरहेड ज्यादातर एक महान कई ब्लॉकों को लिखने के खर्च के साथ जुड़ा हुआ है और ब्लॉक विभाजन को उन पंक्तियों के साथ जोड़ा जाता है जो उस स्तंभ के लिए मौजूदा मूल्य श्रेणियों के "मध्य" में हैं। यह विभाजन द्वारा विभाजित किया जा सकता है और विभाजन योजना के साथ संरेखित नए डेटा लोड होने और प्रत्यक्ष पथ आवेषण का उपयोग करके किया जा सकता है।

आपके प्रश्न को अधिक सीधे संबोधित करने के लिए, मुझे लगता है कि पहली बार में स्पष्ट रूप से अनुक्रमण करना ठीक है, लेकिन यदि तालिका के विरुद्ध प्रश्नों का लाभ होगा तो अधिक अनुक्रमणिका जोड़ने से डरो मत।

Comments

एक तथ्य पर कई? मुझे लगता है कि आप आयाम कहने वाले थे। यह एक अजीब विचित्र है। लेकिन, आप एक डीबीए के रूप में रॉक करते हैं इसलिए मैं कहने वाला हूं, मुझे स्पष्ट रूप से कुछ याद आ रहा है।

— स्टेफनी पेज

@ स्टेफ़नी, हमारे पास एक ही परिदृश्य है .. डेविड ने उन बिटमैप इंडेक्स का उल्लेख किया है। हम BITMAP JOIN इंडेक्स का भी उपयोग करते हैं। हाँ, तथ्यों पर। ओरेकल बिटमैप इंडेक्स पर बहुत कुशल और संचालन कर सकता है। उदाहरण के लिए, आप 5 कम-कार्डिनलिटी विशेषताओं के साथ WHERE क्लॉज़ हो सकते हैं, जिनमें से प्रत्येक में बिटमैप इंडेक्स है। यदि आप निष्पादन योजना को देखते हैं, तो इसमें एक बिटमैप और संचालन (मूल रूप से एक कुशल बिटमैप और संचालन) होगा, फिर निष्पादन योजना के नीचे आप बिटमैप को रूपांतरणों में देखेंगे। यह वास्तव में तेज है।

— तगार

Answer 5

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

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

मेरी सलाह आम और स्पष्ट मामलों को कवर करना है और फिर, जब आप ऐसे मुद्दों का सामना करते हैं, जहां आपको विशिष्ट तालिकाओं से डेटा प्राप्त करने में अधिक गति की आवश्यकता होती है, तो उस बिंदु पर सूचकांक का मूल्यांकन करें और जोड़ें।

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

Comments

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

— ड्यूरेट

Answer 6

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

हमेशा की तरह, कुछ भी सरल नहीं है। यदि तिरछे स्तंभ और हिस्टोग्राम शामिल हैं तो यह एक बुरा विचार हो सकता है।

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

Comments

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

— स्टेफनी पेज

@StephaniePage मैंने कुछ भी साबित करने के लिए एक प्रयोग नहीं किया है। हालाँकि मैंने एक प्रोजेक्ट देखा था जो हर कॉलम पर एक एकल-कॉलम इंडेक्स बनाता था। अगर कुछ तालिकाओं में 80 कॉलम हैं, तो मुझे लगता है कि यह एक प्रभाव बनाने के लिए शुरू कर सकता है। ओरेकल प्रत्येक सूचकांक द्वारा पहुंच की लागत पर विचार करता है। लेकिन हां, मैं मानता हूं, इससे ज्यादा महत्वपूर्ण चीजें हैं।

— डब्ल्यूडब्ल्यू।

मम्म ... मेरा मानना ​​है कि एक अधिकतम समय होता है जो ओरेकल एक कठिन पार्स में खर्च करेगा ... एक एसक्यूएल पर विचार करें जिसमें कुछ तालिकाओं से अधिक हो, 7 या 8 का कहना है, अकेले शामिल होने का आदेश पसंद सैकड़ों संभावित उत्पन्न कर सकता है पहुंच पथ।

— स्टेफनी पेज

Answer 7

मैंने अपनी वास्तविक परियोजना और वास्तविक MySql डेटाबेस पर कुछ सरल परीक्षण किए। मैंने पहले ही इस विषय में उत्तर दिया था: कई db कॉलमों को अनुक्रमित करने की लागत क्या है?

लेकिन मुझे लगता है कि अगर मैं इसे यहाँ उद्धृत करूँ तो बेहतर होगा:

मैंने अपनी वास्तविक परियोजना और वास्तविक MySql डेटाबेस का उपयोग करके कुछ सरल परीक्षण किए।

मेरे परिणाम हैं: एक तालिका में औसत सूचकांक (एक सूचकांक में 1-3 कॉलम) जोड़ना - आवेषण को 2.1% तक धीमा कर देता है। इसलिए, यदि आप 20 इंडेक्स जोड़ते हैं, तो आपका आवेषण 40-50% तक धीमा हो जाएगा। लेकिन आपके चयन 10-100 गुना तेज होंगे।

तो क्या कई सूचकांक जोड़ना ठीक है? - यह निर्भर करता है :) मैंने आपको मेरे परिणाम दिए - आप तय करें!

Comments

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

— सोवियतफ्रंटियर

Answer 8

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

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

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

Answer 9

मेरी राय में कोई स्थिर जवाब नहीं है, इस तरह की बात 'प्रदर्शन ट्यूनिंग' के तहत आती है।

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

केवल अनुक्रमण से परे, गणना की गई खोज फ़ील्ड, बंटवारे तालिका आदि को शामिल करने के लिए आपके डीबी को फिर से व्यवस्थित करना है - यह वास्तव में आपके लोड आकृतियों और क्वेरी मापदंडों पर निर्भर है, एक क्वेरी द्वारा कितना / वास्तव में 'डेटा' को पुनः प्राप्त करने की आवश्यकता है।

यदि आपका पूरा DB संग्रहीत-प्रक्रिया के पहलुओं से बदल जाता है तो मोड़ थोड़ा आसान हो जाता है, क्योंकि आपको प्रत्येक विज्ञापन-होल क्वेरी के बारे में चिंता करने की आवश्यकता नहीं है। या आपके डीबी को हिट करने वाले प्रश्नों की गहरी समझ हो सकती है, और ट्यूनिंग को सीमित कर सकते हैं।

SQL सर्वर के लिए मैंने डेटाबेस इंजन ट्यूनिंग सलाहकार उपयोगी पाया है - आप 'विशिष्ट' कार्यभार सेट करते हैं और यह इंडेक्स और आँकड़ों को जोड़ने / हटाने के बारे में सिफारिशें कर सकता है। मुझे यकीन है कि अन्य डीबी में समान उपकरण हैं, या तो 'ऑफिकल' या थर्ड पार्टी।

Answer 10

यह वास्तव में व्यावहारिक से अधिक सैद्धांतिक प्रश्न है। आपके प्रदर्शन पर इंडेक्स का प्रभाव आपके पास मौजूद हार्डवेयर पर निर्भर करता है, ओरेकल का संस्करण, इंडेक्स प्रकार, आदि। कल मैंने सुना है कि ओरेकल ने एक समर्पित स्टोरेज की घोषणा की है, जो एचपी द्वारा बनाया गया है, जो 11 जी डेटाबेस के साथ 10 गुना तेज प्रदर्शन करने वाला है। आपके मामले के लिए, कई समाधान हो सकते हैं: 1. बड़ी मात्रा में अनुक्रमित (> 20) हैं और उन्हें दैनिक (रात में) पुनर्निर्माण करें। यह विशेष रूप से उपयोगी होगा यदि तालिका को रोजाना हजारों अपडेट / डिलीट मिले। 2. अपनी तालिका (यदि वह आपके डेटा मॉडल को लागू करता है) को विभाजन। 3. नए / अपडेट किए गए डेटा के लिए एक अलग तालिका का उपयोग करें, और एक रात की प्रक्रिया चलाएं जो डेटा को एक साथ जोड़ती है। इसके लिए आपके एप्लिकेशन लॉजिक में बदलाव की आवश्यकता होगी। 4. IOT पर स्विच करें (इंडेक्स संगठित तालिका), यदि आपका डेटा इस का समर्थन करता है।

बेशक ऐसे मामले के लिए कई और समाधान हो सकते हैं। आपके लिए मेरा पहला सुझाव, डीबी को एक विकास के माहौल में क्लोन करना होगा, और इसके खिलाफ कुछ तनाव परीक्षण चलाना होगा।

Comments

मुझे समझ में नहीं आता है कि अनुक्रमणिका का पुनर्निर्माण कैसे मदद करेगा, या IOT कैसे मदद करेगा।

— डेविड एल्ड्रिज

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

— मोशे

एक IOT अभी भी एक इंडेक्स संरचना है, जिसमें नियमित इंडेक्स की तुलना में ब्लॉक विभाजन पर अधिक ओवरहेड होता है। "अनुक्रमणिका का पुनर्निर्माण करना - यदि कई अनुक्रमणिकाएँ हैं, और नए डेटा को अनुक्रमित नहीं किया गया है ..." आप किस RDBMS के बारे में बात कर रहे हैं जो नई प्रविष्टियों के लिए अनुक्रमणिका को स्वचालित रूप से बनाए नहीं रखता है?

— डेविड एल्ड्रिज

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

— मोशे

Answer 11

यदि आप ज्यादातर पढ़ते हैं (और कुछ अपडेट), तो वास्तव में कोई कारण नहीं है कि आप सब कुछ सूचकांक करने की आवश्यकता नहीं है। यदि आप अक्सर अपडेट करते हैं, तो आपको इस बात से सतर्क रहने की आवश्यकता हो सकती है कि आपके पास कितने इंडेक्स हैं। कोई कठिन संख्या नहीं है, लेकिन जब चीजें धीमी होने लगेंगी तो आप देखेंगे। सुनिश्चित करें कि आपका क्लस्टर इंडेक्स वह है जो डेटा के आधार पर सबसे अधिक समझ में आता है।

Answer 12

एक चीज जिस पर आप विचार कर सकते हैं, वह खोजों के एक मानक संयोजन को लक्षित करने के लिए अनुक्रमणिका बना रही है। यदि कॉलम 1 को आमतौर पर खोजा जाता है, और कॉलम 2 को अक्सर इसके साथ प्रयोग किया जाता है, और कॉलम 3 का उपयोग कभी-कभी कॉलम 2 और कॉलम 1 के साथ किया जाता है, तो कॉलम 1, कॉलम 2 और कॉलम 3 पर एक सूचकांक उन तीन परिस्थितियों में से किसी के लिए भी इस्तेमाल किया जा सकता है, हालांकि यह केवल एक सूचकांक जिसे बनाए रखा जाना है।

Answer 13

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

क्या आप अपडेट को पूरा करने में लगने वाले अतिरिक्त समय को बर्दाश्त कर सकते हैं?

आपको लागत और लाभों की तुलना करने की आवश्यकता है। यह आपकी स्थिति के लिए विशेष रूप से है। "बहुत सारे" की दहलीज को पार करने वाले अनुक्रमितों की कोई जादुई संख्या नहीं है।

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

Answer 14

कितने स्तंभ हैं? मुझे हमेशा सिंगल-कॉलम इंडेक्स बनाने के लिए कहा गया है, न कि मल्टी-कॉलम इंडेक्स। तो कॉलम की मात्रा से अधिक कोई इंडेक्स नहीं, IMHO।

Answer 15

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

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

Answer 16

Sql सर्वर आपको कुछ अच्छे टूल देता है जो आपको यह देखने देता है कि वास्तव में कौन से इंडेक्स का उपयोग किया जा रहा है। यह लेख, http://www.mssqltips.com/tip.asp?tip=1239 , आपको कुछ ऐसे प्रश्न देता है, जो आपको इस बात की बेहतर जानकारी देते हैं कि एक इंडेक्स का उपयोग कितना किया जाता है, क्योंकि यह कितना अद्यतन है।

Answer 17

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

Comments

गतिरोध से बचने के लिए विदेशी प्रमुख स्तंभों पर अनुक्रमित? क्या आपके पास एक संदर्भ है जो बताता है कि यह मामला क्यों और कैसे है?

— जय सुलिवन