2009-08-14 15 views
15

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

कभी-कभी यह पर्याप्त होता है अगर मैं सही तरीके से अनुक्रमणित कर रहा हूं, कभी-कभी नहीं। मैंने कहीं पढ़ा है (अगर यह मूर्खता है तो कृपया मुझे सही करें) कि मुझे जितना अधिक इंडेक्स चाहिए, वही प्रभाव डालें, जैसे कि मेरे पास कोई इंडेक्स नहीं है।

कितने अनुक्रमणिका पर्याप्त हैं? आप कह सकते हैं कि यह सैकड़ों कारकों पर निर्भर करता है, लेकिन मैं उत्सुक हूं कि मैं अपने mysql-slow.log को सर्वर लोड को कम करने के लिए पर्याप्त कैसे साफ कर सकता हूं।

# Query_time: 0 Lock_time: 0 Rows_sent: 22 Rows_examined: 44 
SELECT * FROM `categories` ORDER BY `orderid` ASC; 

प्रश्न में तालिका वास्तव में 22 पंक्तियाँ, सूचकांक orderid में सेट शामिल हैं:

इसके अलावा, मैं इस तरह कुछ "दिलचस्प" लॉग प्रविष्टियों को देखा। यह प्रश्न लॉग में क्यों दिख रहा है? 44 पंक्तियों की जांच क्यों करें यदि इसमें केवल 22 शामिल हैं?

+0

मुझे लगता है कि यह एक प्रकार है, इसलिए यह किसी भी तरह की पंक्ति को कई बार जांचता है: x – Lliane

+0

एक्स्पलाइन चयन * ऑर्डर आईडी 'ऑर्डर द्वारा' ऑर्डर 'के लिए क्या लौटाया जाता है; – Powerlord

+0

@ आर। Bemrose: यदि मैं सही करता हूं तो यह अतिरिक्त देता है: filesort का उपयोग करना। शायद यह समस्या है? – fabrik

उत्तर

22

अनुक्रमण की मात्रा और बहुत अधिक करने की रेखा बहुत सारे कारकों पर निर्भर करेगी। अपनी "श्रेणियों" तालिका जैसी छोटी सारणी पर आप आमतौर पर एक इंडेक्स नहीं चाहते हैं या इसकी आवश्यकता नहीं है और यह वास्तव में प्रदर्शन को नुकसान पहुंचा सकता है। कारण यह है कि यह एक सूचकांक पढ़ने के लिए I/O (यानी समय) लेता है और फिर मिलान की पंक्तियों से जुड़े रिकॉर्ड्स को पुनर्प्राप्त करने के लिए और अधिक I/O और समय लेता है। एक अपवाद तब होता है जब आप केवल इंडेक्स में निहित कॉलम से पूछताछ करते हैं।

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

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

अपना विश्लेषण करते समय, अपनी तालिका और अनुक्रमणिका आंकड़े जेनरेट/अपडेट करना सुनिश्चित करें ताकि आपको सटीक गणना का आश्वासन दिया जा सके।

+0

धन्यवाद! यह मेरे लिए सबसे स्पष्ट और सहायक उत्तर था! – fabrik

+0

आप मेमोरी में टेबल को 'पिन' कैसे करते हैं? –

+0

मैं MySQL को स्मृति में 'पिन' करने के लिए कैसे बता सकता हूं? – satoru

3

इंडेक्स की "सर्वश्रेष्ठ" संख्या के लिए कोई जादू संख्या नहीं है। मूल नियम यह है: अक्सर पूछे जाने वाले प्रश्नों के लिए अनुक्रमणिका जोड़ें और/या जल्दी से चलाने की आवश्यकता है।

"बहुत अधिक" इंडेक्स होने से प्रश्नों को धीमा नहीं करना चाहिए, लेकिन यह प्रत्येक इंडेक्स में डीबी में वस्तुओं को जोड़ने/अपडेट करने के लिए थोड़ी सी मात्रा जोड़ती है (क्योंकि यह इंडेक्स को भी संशोधित करती है), और एक छोटी राशि जगह का। हालांकि, अगर आप केवल आवश्यकतानुसार इंडेक्स जोड़ रहे हैं, तो शायद यह एक बड़ी चिंता नहीं है।

13

एक सामान्य नियम के रूप में, आपके पास सभी प्राथमिक कुंजी (आपके पास उसमें कोई विकल्प नहीं है), सभी विदेशी कुंजी, और अन्य फ़ील्ड जो आप आम तौर पर पंक्तियों को लाने के लिए उपयोग करते हैं, पर इंडेक्स होना चाहिए।

उदाहरण के लिए, यदि मैं आमतौर पर उपयोगकर्ता नाम से उपयोगकर्ताओं को देखता हूं, तो मैं उस अनुक्रमित होता, भले ही उपयोगकर्ता आईडी प्राथमिक कुंजी थी।

6

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

इस जानकारी का उपयोग करके आप तय कर सकते हैं कि अपनी टेबल को कैसे कुंजी करें और/या उन्हें अधिक कुशल बनाने के लिए अपने प्रश्नों को संशोधित करें। व्याख्या के लिए वाक्यविन्यास बहुत आसान है।

EXPLAIN SELECT * FROM `categories` ORDER BY `orderid` ASC; 

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

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

+0

ग्रेट टिप्पणी, धन्यवाद! – fabrik

4

एक इंडेक्स एक SELECT क्वेरी को तेज कर सकता है, लेकिन यह INSERT/UPDATE/DELETE क्वेरी को धीमा कर देगा क्योंकि उन्हें सूचकांक को भी अद्यतन करने की आवश्यकता है, न केवल पंक्ति।

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

+0

"करने के लिए एक मूर्ख चीज प्रत्येक कॉलम पर एक इंडेक्स रखना होगा" क्योंकि यह पूरी तरह ठीक है लेकिन मैं जितनी धीमी-लॉग प्रविष्टियों को समाप्त कर सकता हूं उतना ही खत्म करना चाहता हूं। अन्यथा INSERT/UPDATEs/DELETEs पर विचारों के लिए धन्यवाद! – fabrik

5

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

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