2010-05-21 8 views
9

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

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

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

धन्यवाद!

:

[संपादित पहचान कॉलम "पहचान विनिर्देश" का उपयोग नहीं कर रहे हैं, वे इस कार्यक्रम के द्वारा स्थापित किया जाना, प्रबंधन स्टूडियो के साथ डेटाबेस को देखकर लगता है, मैं नहीं अनुक्रमित ... पा सकते हैं] FOLLOWUP: एक सम्मेलन में मैंने इस उत्पाद को उत्पादित करने वाले कंपनी के सीईओ (और मुख्य वास्तुकार) से पूछा, उनकी प्रतिक्रिया यह थी कि वे छोटे से मिडियोज़ तैनाती के लिए महसूस करते थे, इंडेक्स को बनाए रखने के साथ जुड़े ओवरहेड में कुल उपयोगकर्ता के लिए नकारात्मक होगा इंडेक्स के फायदे की तुलना में अनुभव (एप्लिकेशन बहुत सारे लिखते हैं), लेकिन बड़े डेटाबेस के लिए, वे इंडेक्स बनाते हैं। तकनीकी सहायता लड़का सिर्फ अपने जवाब के साथ अति उत्साही और बहुत ही अनुपयोगी था। रहस्य सुलझ गया।

उत्तर

3

मुझे किराया और मैं आपके लिए इंडेक्स बनाउंगा। 14 साल का Sybase/SQL सर्वर अनुभव मुझे उनको बनाने के लिए कहता है! डर्न! अनुक्रमित। जब तक आपकी तालिका में 500 से कम रिकॉर्ड न हों।

मेरा विचार है कि एक सूचकांक हैश नोड मोटे तौर पर 1000

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

हालांकि, यदि उसके पास वास्तव में 500 कॉलम हैं या प्रति तालिका में कई वैचारिक संस्थाएं हैं - वह एक बहुत ही लुभावनी डेटा डिजाइन इंजीनियर है। मेरे सभी वर्षों में अधिक अनुभवी डेटा इंजीनियरों के साथ काम करते हुए, हमारी टेबल शायद ही कभी 20 कॉलम से अधिक हो जाती है। 5 कम तरफ, औसत पर 10। कभी-कभी प्रदर्शन के लिए हम एक टेबल में दो इकाइयों को मिश्रण करने की अनुमति देते हैं, या तालिका के कॉलम में क्षैतिज पंक्ति उत्पन्न होते हैं।

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

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

ठीक है, लैरी के पोस्ट पढ़ने के बाद - मैं भी उससे सहमत हूं।

+0

बहुत सारे कॉलम वाले कुछ टेबल हैं, लेकिन उनमें कई वैचारिक इकाइयां नहीं लगती हैं। बड़ी तालिकाओं (कॉलम-वार) में बहुत सारी विशेषता-डेटा है जो उस तालिका में एक उचित समूह में प्रतीत होता है। – Aerik

+0

मैंने देखा है कि मैंने सोचा था कि 30 कॉलम के साथ एक अच्छी मेज थी। लेकिन हाँ टेबल लगभग 5 पर केंद्रित एक पोइसन वितरण का पालन करें। – Joshua

0

आईडी कॉलम पर इंडेक्स नहीं होने पर वास्तव में असामान्य लगता है और मुझे बहुत ही गड़बड़ी करने के लिए उन्हें शामिल करने के लिए कोई औचित्य नहीं मिलेगा।

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

यह बेहतर होगा कि अतिरिक्त इंडेक्स जोड़ने से समस्याएं कैसे हो सकती हैं।

3

क्या आपके पास डिस्क स्थान शेष है? मैंने उन मामलों को देखा है जहां इंडेक्स तालिका से अधिक वजन कम करते हैं।

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

+0

हमारे पास बहुत सी डिस्क स्पेस है। और हमारा मामला बहुत विशिष्ट है: बड़ी तालिका, और एक पठन ऑपरेशन आमतौर पर एक विशिष्ट पंक्ति की तलाश कर रहा है, या एक चयन शीर्ष कर रहा है ... क्वेरी द्वारा आदेश। तो यह पूरी टेबल नहीं पढ़ रहा है। – Aerik

+0

वास्तव में यह है - सूचकांक के बिना। किसी भी सूचकांक के बिना यह केवल कुछ भी के लिए पूरी तालिका पढ़ सकते हैं। – TomTom

+1

शीर्ष पर चयन करें ... ऑर्डर द्वारा आदेश पर एक सूचकांक से लाभ से ऑर्डर करें। – Joshua

2

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

यह भी इस बात पर निर्भर करता है कि आपका डेटा कितना सम्मिलित है। यदि आप पूछताछ से अधिक बार सम्मिलित कर रहे हैं, तो इंडेक्स को अद्यतित रखने का ओवरहेड आपके आवेषण को धीमा कर सकता है।

लेकिन कहने के लिए कि आपको "किसी भी परिस्थिति में [इंडेक्स] बनाना नहीं चाहिए" थोड़ा सा है।

मैं क्या सुझाव दूंगा कि आप अपने प्रश्नों के साथ SQL Server Profiler उपकरण चलाएं। यह टूल अनुशंसा करेगा कि कौन से इंडेक्स जोड़े जाएंगे, इसका प्रदर्शन पर सबसे बड़ा असर होगा।

+0

उद्देश्य से पुनर्प्राप्त नहीं कर रहा है। आवेदन निश्चित रूप से लिखने की तुलना में पढ़ने की दिशा में बहुत अधिक है - ऐसा लगता है कि यह बहुत भयानक है – Aerik

+0

में शामिल होने के बजाय अलग-अलग चयन मैंने SQL सर्वर प्रोफाइलर टूल के बारे में कुछ जोड़ा है। महंगा "सलाहकार" से बहुत सस्ता है जो अपने गधे से बात करते हैं, और वास्तव में काफी प्रभावी भी हैं;) –

+0

प्रोफाइलर टूल के सुझाव के लिए धन्यवाद - मैंने पहले ही "हाथ से" अनुकूलन किया है। मुझे लगता है कि हमारा असली मुद्दा यह होगा कि हम परामर्शदाता की सिफारिश के खिलाफ जाने के इच्छुक हैं या नहीं। असली जिंजर यहां वह कंपनी से है जिसने आवेदन लिखा था। – Aerik

0

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

1

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

जैसा कि बताया गया है, डिस्क स्थान एक मुद्दा हो सकता है।

अप्रासंगिक इंडेक्स (उदा। डुप्लीकेट) बनाना भी माइक्रोसेकंड को बर्बाद कर देगा और कभी-कभी खराब क्वेरी निष्पादन योजना में परिणाम देगा।

मैंने जो दूसरी समस्या देखी है वह अजीब कोड तीसरे पक्ष के अनुप्रयोगों के साथ है जो रनटाइम पर डेटाबेस के कुछ हिस्सों को उत्पन्न करती है, और उन इंडेक्स पर हटा या दबा सकती है जिन्हें वे नहीं जानते हैं।

हालांकि अधिकांश मामलों में सावधानीपूर्वक चुने गए सूचकांक केवल लाभ होंगे।

3

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

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

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

+0

मुझे वास्तव में संदेह है कि वह इस तरह की चमकदार निगरानी के लिए कवर कर रहा है - कि हमारी कंपनी हमें यह जानने के बजाय बुरी सलाह देगी कि वे अपने डिजाइन में डेटाबेस इंडेक्स की तरह कुछ चूक गए हैं। – Aerik

+0

या तो वह, या वह कुल मूर्ख है। कई परियोजनाओं में देखा गया, यह भी देखा गया - कुछ फ़ील्ड बनाने वाले कुछ बंकहेड डेटाबेस विशेषज्ञ सहित सभी फ़ील्ड टेक्स्ट फ़ील्ड ऑब्जेक्ट मॉडल का हिस्सा नहीं था (ergo: गैर अनुक्रमणीय-उत्पाद संख्या जैसे कुछ भी नहीं)। उस क्षेत्र के आसपास के लोग, और कभी-कभी सलाहकार के रूप में होते हैं। दुख की बात है। – TomTom

+0

अगर मुझे लंबाई के बिना करना पड़ा तो मैं postgresql का उपयोग करता हूं जिसमें वर्कर (2000000000) मान्य और अनुक्रमणीय है और वर्चर (100) से अधिक लागत नहीं लेता है अगर यह वर्चर (100) की आवश्यकता होती है तो आपको इसकी आवश्यकता होती है। – Joshua

संबंधित मुद्दे