जवाबों:
क्या मुझे शुरू से ही इंडेक्सिंग शुरू करनी चाहिए या जब प्रदर्शन की समस्या उत्पन्न होती है?
इंडेक्सिंग रणनीति उपयोग पैटर्न विकसित होने के रूप में विकसित होती है। उस ने कहा, वहाँ भी रणनीति और डिजाइन दिशा निर्देश है कि सामने लागू किया जा सकता है।
एक अच्छी क्लस्टरिंग कुंजी चुनें । आप आम तौर पर एक तालिका में आवेषण के अपेक्षित पैटर्न के आधार पर, डिज़ाइन समय पर उपयुक्त क्लस्टर इंडेक्स निर्धारित कर सकते हैं। यदि भविष्य में बदलाव के लिए एक सम्मोहक मामला सामने आता है, तो ऐसा ही हो।
अपनी प्राथमिक और अन्य अनूठी बाधाओं को बनाएं । इन्हें यूनिक इंडेक्स द्वारा लागू किया जाएगा।
अपनी विदेशी कुंजियाँ और संबद्ध गैर-संकुल अनुक्रमणिकाएँ बनाएँ । विदेशी कुंजियाँ आपके सबसे अक्सर संदर्भित जॉइन कॉलम हैं, इसलिए उन्हें प्रारंभ से अनुक्रमित करें।
स्पष्ट रूप से अत्यधिक चयनात्मक प्रश्नों के लिए अनुक्रमित बनाएं । क्वेरी पैटर्न के लिए आप पहले से ही जानते हैं कि स्कैन के बजाय लुकअप का उपयोग करने के लिए अत्यधिक चयनात्मक और संभावना होगी।
उपरोक्त से परे, नए अनुक्रमित को लागू करने के लिए एक क्रमिक और समग्र दृष्टिकोण लें। समग्र रूप से, मेरा मतलब है कि अतिरिक्त मूल्यांकन करते समय सभी प्रश्नों और मौजूदा अनुक्रमितों के संभावित लाभ और प्रभाव का आकलन करें।
अनुपलब्ध अनुक्रमणिका DMV और SSMS संकेत से मार्गदर्शन के परिणामस्वरूप SQL सर्वर मंडलियों में कोई असामान्य समस्या नहीं है। इनमें से कोई भी उपकरण मौजूदा इंडेक्स का मूल्यांकन नहीं करता है और यह सुझाव देगा कि आप मौजूदा 5 कॉलम इंडेक्स में एकल कॉलम जोड़ने के बजाय एक नया 6 कॉलम इंडेक्स बनाएं।
-- If you have this
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
)
-- But your query would benefit from the addition of a column
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)
-- SSMS will suggest you create this instead
CREATE NONCLUSTERED INDEX [IX_MyTable_AnotherIndexWithTheSameColumnsAsTheExistingIndexPlusCol6] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)
किम्बर्ली ट्रिप के पास इंडेक्सिंग रणनीति पर कुछ उत्कृष्ट सामग्री है, जबकि एसक्यूएल केंद्रित अन्य प्लेटफार्मों पर लागू होता है। SQL सर्वर लोक के लिए, ऊपर दिए गए उदाहरण की तरह डुप्लिकेट की पहचान करने के लिए कुछ उपयोगी उपकरण हैं।
हम किसी क्वेरी को निष्पादित करते समय अस्थायी सूचकांक भी बना सकते हैं। इस तरह की तकनीकों के पेशेवरों और विपक्ष क्या हैं?
यह आम तौर पर ईटीएल, आमतौर पर रन क्वेरी के लिए ही लागू होता है। आपको आकलन करने की आवश्यकता है:
वास्तव में दोनों दृष्टिकोणों से जुड़े जोखिम हैं:
विकल्प) शुरू से ही सूचकांक, लेकिन एहसास नहीं कि आपने कई सूचकांक बनाए हैं जो कभी उपयोग नहीं किए जाते हैं। ये कुछ ओवरहेड जोड़ते हैं (डेटा को संशोधित करने वाले प्रश्नों पर सबसे अधिक ध्यान देते हैं, लेकिन सबसे अच्छे सूचकांक की पहचान करने की कोशिश कर रहे सेलेक्ट स्टेटमेंट के अनुकूलन के साथ भी)।
अब उपयोग किए जा रहे इंडेक्स की पहचान करने और उन्हें आज़माने और हटाने के लिए आपको खुद को अनुशासित करने की आवश्यकता होगी (PostgreSQL ऐसा कर सकता है; दुर्भाग्य से तुलना करके MySQL इस बॉक्स से बाहर बहुत कमजोर है।)
विकल्प b) जब तक लोग शिकायत करना शुरू नहीं करते हैं, या आपके नैदानिक उपकरण ट्रिगर नहीं करते हैं कि कुछ प्रश्न धीमे हैं और उन्हें सुधारा जा सकता है।
आपके द्वारा पेश किया जाने वाला जोखिम यह है कि आपके पास एक बड़ी पर्याप्त समय खिड़की नहीं है जब आप नोटिस करते हैं कि आपको सूचकांक की आवश्यकता है, और जब आपको इसे जोड़ना होगा।
PostgreSQL बिल्डिंग इंडेक्स का समर्थन करता है CONCURRENTLY, जो इस अचानक-इंडेक्स-ऐड-आवश्यकता से कुछ तनाव को कम करता है, लेकिन मैनुअल में कुछ कैविएट नोट किए गए हैं।
विकल्प (बी) मेरी पसंद है, लेकिन मुझे लगता है कि दोनों विकल्पों में से एक संकर शायद सबसे अच्छा समाधान है। यह आपके विश्वास स्तर के साथ करना है कि क्या आपको लगता है कि वास्तव में एक सूचकांक का उपयोग किया जाएगा।
यह एक विशेष रूप से जटिल चर्चा करता है कि आमतौर पर अनुक्रमित को बदलना आसान है, लेकिन स्कीमा को बदलना कठिन है। मैं लापरवाह होने के बहाने के रूप में ख के विलंबित प्रतिक्रिया को बढ़ावा नहीं देना चाहता ।
मार्क के जवाब के अलावा
आप अपेक्षित मात्रा में यथार्थवादी परीक्षण डेटा प्राप्त करके महसूस कर सकते हैं। मैंने कई, कई (बहुत सारे) मामलों को देखा है जहां एक प्रश्न 1000 पंक्तियों के साथ ठीक चलता है लेकिन उत्पादन में मिलियन नहीं।
यदि आप बाद में उत्पादन की एक प्रति पर काम कर सकते हैं,
बेशक, मैंने उपयोग पैटर्न के कारण केवल उत्पादन में विषम समस्या देखी है जब बाकी सब कुछ समान है
अस्थायी सूचकांक? ईटीएल लोड पैटर्न के बाहर, अगर आपको उनकी आवश्यकता है तो एक बार आपको उनकी आवश्यकता होगी। मत भूलो: एक इंडेक्स क्रिएट / ड्रॉप एक लेखन है और लॉग इन किया जाता है = अधिक लोड
बस कुछ चीजें जोड़ने के लिए।
यह मेरा दृष्टिकोण है।
अप्रयुक्त स्तंभों के लिए जहां > 0या > ""जहां क्लॉस लगाए जाते हैं, वहां डरो मत ।
select * from blah
where A="one"
and B="two"
and C>="" --to match index
and D="four"
--This will use your existing index. No need to create a redundant one.मैं केवल पहले प्रश्न का उत्तर देने का प्रयास करूंगा। यदि आप शुरू से ही मोटे तौर पर अनुमान लगा सकते हैं कि एक निश्चित समय के बाद आपके टेबल में कितने रिकॉर्ड होंगे, तो मैं कहूंगा कि कुछ इंडेक्सों को डिजाइन करने के लिए शुरुआत से शुरुआत करना बेहतर है। कुछ परीक्षण उपकरण या परीक्षण स्क्रिप्ट का उपयोग करने का प्रयास करें जो आपके द्वारा किए गए एप्लिकेशन कॉल के लिए जितनी संभव हो उतने कॉल को स्वचालित करेगा, आपको सबसे अधिक बार उपयोग किया जाएगा और आप देखेंगे कि टेबल स्कैन को शुरुआत से कैसे बचा जा सकता है।
यह शुरुआत में अनुमान लगाने वाला काम होगा, लेकिन समय के साथ, जैसा कि आपके पास उचित उपयोग के आँकड़े हैं, आपके पास एक स्पष्ट छवि होगी।