क्या तरीकों/तकनीक का अनुभव एसक्यूएल डेवलपर्स के कुछ निर्धारित करने के लिए एक विशेष SQL क्वेरी लोड बढ़ जाती है के रूप में अच्छी तरह से स्केल करेगा का उपयोग कर रहे हैं, संबद्ध तालिकाओं में पंक्तियों में वृद्धि आदिकैसे बताना है कि कोई प्रश्न अच्छी तरह से स्केल करेगा या नहीं?
कुछ नियम जो मैं पालन करता हूं, उनमें सबसे अधिक अंतर होता है।
if, case, coalesce और इतने पर की तरह अपने प्रश्नों में उपयोग नहीं प्रति-पंक्ति कार्यों करो। उस प्रारूप में डेटाबेस में डेटा डालकर उनके चारों ओर काम करें, जिसकी आपको आवश्यकता होगी, भले ही इसमें डुप्लिकेट डेटा शामिल हो।
उदाहरण के लिए, यदि आपको उपनामों को तेज़ी से देखने की आवश्यकता है, तो उन्हें अपने लोअरकेस फॉर्म में दर्ज फॉर्म और में स्टोर करें, और लोअरकेस फॉर्म को इंडेक्स करें। तो आपको select * from tbl where lowercase(surname) = 'smith';
हाँ, मुझे पता है कि 3 एनएफ तोड़ता है लेकिन आप अभी भी ट्रिगर या पूर्व-गणना कॉलम के उचित उपयोग से डेटा अखंडता की गारंटी दे सकते हैं। उदाहरण के लिए, तालिका पर एक सम्मिलित/अद्यतन ट्रिगर कॉलम को surname के लोअरकेस संस्करण पर सेट करने के लिए मजबूर कर सकता है।
यह रूपांतरण की लागत insert/update (जो अक्सर होता है) और select से दूर चला जाता है (जो काफी अधिक होता है)। आप मूल रूप से रूपांतरण की लागत को कम करते हैं।
सुनिश्चित करें कि एक where खंड में प्रयोग किया जाता हर स्तंभ अनुक्रमित किया गया है। जरूरी नहीं कि अपने आप पर लेकिन कम से कम एक समग्र कुंजी के प्राथमिक भाग के रूप में।
हमेशा 3NF में शुरू और केवल वापस लौटने अगर आप प्रदर्शन की समस्याओं (उत्पादन में ) है। 3 एनएफ अक्सर संभालने और बदलने के लिए सबसे आसान होता है जब पूरी तरह से आवश्यक हो।
प्रोफ़ाइल, उत्पादन में (या कहीं और, जब तक आपके पास उत्पादन डेटा और स्कीमा है)।डाटाबेस ट्यूनिंग एक सेट-एंड-भूल ऑपरेशन नहीं है जब तक कि आपकी टेबल में डेटा कभी भी बदल नहीं जाता (बहुत दुर्लभ)। डेटा को बदलने से संभावना को कम करने की संभावना से बचने के लिए आपको समय-समय पर निगरानी और संभावित रूप से ट्यूनिंग की जानी चाहिए।
जब तक पूरी तरह से आवश्यक न हो, तो अपने डेटाबेस में नग्न प्रश्नों की अनुमति न दें। यह नियंत्रित करने का प्रयास करें कि कौन से प्रश्न चल सकते हैं। एक डीबीए के रूप में अपनी नौकरी में बहुत कठिन काम करता है, तो कुछ प्रबंधक साथ आ सकते हैं और सिर्फ चलेंगे:
select * from very_big_table order by column_without_index;
।
यदि प्रबंधक विज्ञापन-प्रसार क्वेरी चलाने में सक्षम होना चाहते हैं, तो उन्हें एक क्लोन डीबीएमएस (या प्रतिकृति) दें ताकि आपके वास्तविक उपयोगकर्ता (जिन्हें प्रदर्शन की आवश्यकता हो) प्रभावित नहीं हैं।
union का उपयोग करते हैं union all पर्याप्त होगा न करें। यदि आप जानते हैं कि संघ के दो चयनों के बीच कोई डुप्लीकेट नहीं हो सकता है, तो डीबीएमएस को हटाने की कोशिश करने का कोई मतलब नहीं है।
इसी तरह, यदि आप सभी प्राथमिक कुंजी कॉलम (या एक अद्वितीय बाधा में सभी कॉलम) पुनर्प्राप्त कर रहे हैं, तो तालिका पर select distinct का उपयोग न करें। नहीं उन मामलों में डुप्लिकेट की संभावना है, फिर से, आप डीबीएमएस को अनावश्यक काम करने के लिए कह रहे हैं।
उदाहरण: हमारे पास एक तालिका में select distinct * का उपयोग करके एक दृश्य था। दृश्य को पूछने में 50 सेकंड लग गए। जब हमने इसे select * से शुरू करने के दृश्य के साथ बदल दिया, तो समय उप-सेकंड में आया। कहने की जरूरत नहीं, मैं जितना संभव हो उतना select * से बचने की कोशिश है कि :-) के
बाहर रेड वाइन का एक अच्छा बोतल मिल गया। दूसरे शब्दों में, केवल आपको आवश्यक कॉलम प्राप्त करें। जब आप अपने स्थानीय पीसी पर MySQL का उपयोग कर रहे हों तो इससे थोड़ा अंतर होता है, लेकिन जब आपके पास कैलिफ़ोर्निया में इनर मंगोलिया में डेटाबेस की क्वेरी करने वाला ऐप होता है, तो आप जितना संभव हो सके तार में भेजे जा रहे ट्रैफ़िक की मात्रा को कम करना चाहते हैं।
इसे डेटा की एक श * tload झोंक देना और प्रोफ़ाइल।
यही कारण है, और सुनिश्चित करें कि यह, उन्हें संकीर्ण के साथ-साथ अनुक्रमित रखने अनुक्रमण, स्कीमा डिजाइन, आदि
टेबल विस्तृत नहीं बनाते हैं के लिए सर्वोत्तम प्रथाओं इस प्रकार है। सुनिश्चित करें कि प्रश्न पूरी तरह से इंडेक्स द्वारा कवर किए गए हैं और ये प्रश्न SARGable हैं।
उत्पादन में जाने से पहले डेटा की एक टन के साथ टेस्ट, इस पर एक नज़र डालें: Your testbed has to have the same volume of data as on production in order to simulate normal usage
रॉबर्ट के सुझाव के अलावा (और उसी तर्ज पर) में, कार्य योजना लागू करने पर विचार। क्या यह इंडेक्स का उपयोग कर रहा है? क्या कोई स्कैन या ऐसा है? क्या आप बस किसी भी तरह से क्वेरी के लिए कर सकते हैं? उदाहरण के लिए, IN को EXISTS के पक्ष में हटाएं और केवल में शामिल होने के लिए की तालिका में शामिल हों।
आप प्रौद्योगिकी का जिक्र नहीं करते हैं - ध्यान रखें कि विभिन्न तकनीकें अधिक जटिल प्रश्नों की दक्षता को प्रभावित कर सकती हैं।
कार्य योजना लागू करके ऊपर खींचें और निम्न में से किसी के लिए देखो:
इनमें से कोई भी चीज (सबसे कम से कम स्केलेबल से अवरोही क्रम में) का मतलब है कि डेटाबेस/क्वेरी स्केल बहुत बड़ी टेबल तक नहीं होगी। एक आदर्श प्रश्न में अधिकांश इंडेक्स में शामिल होना होगा, हैश या विलय, कभी-कभी सॉर्ट और अन्य कम-प्रभाव वाले ऑपरेशन (स्पूल और इसी तरह) में विलय करना होगा।
यह साबित करने का एकमात्र तरीका है कि स्केल होगा, जैसा कि अन्य उत्तरों ने इंगित किया है, वांछित आकार के डेटा पर इसका परीक्षण करना है। उपरोक्त अंगूठे का नियम है।
मैं इस पर कुछ संदर्भ सामग्री पढ़ने की दृढ़ता से अनुशंसा करता हूं।यह (नीचे हाइपरलिंक) शायद देखने के लिए एक बहुत अच्छी किताब है। अन्य विषयों के बीच, "चयनकता" के अंतर्गत देखना सुनिश्चित करें।