इंडेक्स करें जो सबसे तार्किक लगता है (जो उम्मीद के मुताबिक स्पष्ट होना चाहिए, उदाहरण के लिए, ग्राहक तालिका में एक ग्राहक आईडी कॉलम)।
फिर अपना एप्लिकेशन चलाएं और डेटाबेस कैसा प्रदर्शन कर रहा है यह देखने के लिए समय-समय पर आंकड़े एकत्र करें। DB2 पर RUNSTATS एक उदाहरण है, मुझे आशा है कि MySQL के पास एक समान टूल होगा।
जब आप कुछ बार-बार चलने वाली क्वेरी को पूर्ण तालिका स्कैन करते हुए पाते हैं (या अन्य कारणों से बहुत अधिक समय लेते हैं), तो, और उसके बाद ही , क्या आपको और इंडेक्स जोड़ना चाहिए। महीने में एक बार चलने वाली आधी रात की क्वेरी को ऑप्टिमाइज़ करना थोड़ा अच्छा होता है ताकि यह 12:07 के बजाय 12:05 पर समाप्त हो सके। हालांकि, ग्राहक-सामना करने वाली क्वेरी को 5 सेकंड से घटाकर 2 सेकंड करना एक बहुत बड़ा सुधार है (यह अभी भी बहुत धीमा है, यदि संभव हो तो ग्राहक-सामना करने वाली क्वेरी उप-सेकंड होनी चाहिए)।
अधिक इंडेक्स इन्सर्ट को धीमा करते हैं और प्रश्नों को गति देते हैं। तो यह हमेशा एक संतुलनकारी कार्य है। इसलिए आप किसी समस्या के विशिष्ट प्रतिक्रिया में केवल अनुक्रमणिका जोड़ते हैं। और कुछ भी समयपूर्व अनुकूलन है और इससे बचा जाना चाहिए।
इसके अलावा, यह देखने के लिए कि क्या वे अभी भी आवश्यक हैं, समय-समय पर आपके पास पहले से मौजूद अनुक्रमणिका को फिर से देखें। हो सकता है कि जिन प्रश्नों के कारण आपने उन अनुक्रमणिकाओं को जोड़ा है, वे अब पर्याप्त रूप से नहीं चलाई जातीं।
ईमानदार होने के लिए, मुझे विश्वास नहीं है कि एक टेबल पर तीन कॉलम इंडेक्स करने से आपको नुकसान होगा जब तक कि आप वास्तव में बड़ी संख्या में पंक्तियों को संग्रहीत करने की योजना नहीं बनाते :-) - अनुक्रमण बहुत कुशल है।
आपके संपादन के बाद जो बताता है:
मेरी प्रतिक्रिया यह है कि एक दिन में 200 रिकॉर्ड एक डेटाबेस के लिए एक बहुत ही छोटा मूल्य है, आपको निश्चित रूप से उन तीन इंडेक्स के बारे में चिंता करने की कोई बात नहीं होगी।
इस हफ्ते, मैंने काम पर हमारे डेटाबेस टेबल में से एक में एक दिन के लेन-देन का आयात किया और इसमें 2.1 मिलियन रिकॉर्ड शामिल थे (हमें पूरे दिन में कम से कम एक लेनदेन प्रति सेकंड 25 अलग-अलग मशीनों से मिलता है)। और इसमें चार अलग-अलग मिश्रित कुंजियाँ हैं जो आपकी तीन अलग-अलग कुंजियों की तुलना में कुछ अधिक गहन हैं।
अब दी गई है, यह एक DB2 डेटाबेस पर है, लेकिन मैं कल्पना नहीं कर सकता कि IBM तो . है MySQL लोगों की तुलना में बहुत बेहतर है कि MySQL केवल 0.01% से कम DB2 लोड को संभाल सकता है।
