क्वेरी प्रदर्शन; यकीन नहीं क्या

Question

मैं था मेरी क्वेरी के साथ मुद्दों है कि निष्पादित करने के लिए 17 सेकंड लिया (350k पंक्तियाँ) हो रहा है:

SELECT idgps_unit, MAX(dt) 
     FROM gps_unit_location 
     GROUP BY 1 

के बारे में बताएं

1 SIMPLE gps_unit_location index  fk_gps2 5  422633 

इसके साथ खेलने के बाद, मैं इस समाधान है कि लेता है के साथ आया था 1second:

Select idgps_unit, MAX(dt) from (
SELECT idgps_unit, dt 
     FROM gps_unit_location 
) d1 
Group by 1 

के बारे में बताएं:

1 PRIMARY <derived2> ALL     423344 Using temporary; Using filesort 
2 DERIVED gps_unit_location index  gps_unit_location_dt_gpsid 10  422617 Using index 

और अब मैं उलझन में हूं- क्यों क्वेरी # 2 तेज है, जबकि क्वेरी # 1 एक ही प्रश्न प्रतीत होता है और लगता है कि यह अधिक कुशलतापूर्वक लिखा गया है।

Index1: डीटी, Index2: idgps_unit, Index3: idgps_unit + डीटी

निष्पादन समय संगत कर रहे हैं; क्वेरी # 1 हमेशा 17-19sec लेता है; जबकि #1sec।

मैं Godaddy VPS Windows सर्वर का उपयोग कर रहा 2008 अर्थव्यवस्था

तालिका उदाहरण:

id | idgps_unit | dt | location 
1 | 1 | 2012-01-01 | 1 
2 | 1 | 2012-01-02 | 2 
3 | 2 | 2012-01-03 | 3 
4 | 2 | 2012-01-04 | 4 
5 | 3 | 2012-01-05 | 5 

Answer 1

सबसे पहले, मुझे लगता है कि gps_unit_location वास्तव में एक टेबल है और एक दृश्य नहीं है। दूसरा, मैं यह भी मान रहा हूं कि आपने कई बार दोनों प्रश्नों को चलाया है, इसलिए कैशिंग स्पष्टीकरण नहीं है। (कैशिंग यह होगी कि आप पहली क्वेरी चलाते हैं, यह तालिका को पृष्ठ कैश में लोड करता है और दूसरा डिस्क की बजाय स्मृति से पढ़ता है।)

क्या आपके पास gps_unit_location(idgps_unit) पर कोई अनुक्रमणिका है? क्या रिकॉर्ड बहुत व्यापक हैं? यदि इन सवालों के जवाब "हां" हैं, तो निम्न हो रहा है।

यदि ऐसा है, तो आपको अनुक्रमण के साथ एक उत्सुक समस्या हो सकती है। आपको लगता है कि एक सूचकांक ऐसी क्वेरी को तेज करेगा। हालांकि, यह idgps_id में मानों को देखने के लिए है। यदि अनुक्रमणिका में दिनांक नहीं है, तो डेटाबेस को प्रत्येक पृष्ठ से डेटा लाने की आवश्यकता है। यदि तालिका स्मृति में फिट नहीं होती है, तो यह अक्सर कैश-मिस का परिणाम होगा - यानी, पृष्ठ लोड करने का समय।

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

मेरा अनुमान है कि दूसरी संरचना इंडेक्स के उपयोग को हटा देती है।

वैसे, आप इंडेक्स को gps_unit_location(idgps_unit, dt) पर बदलकर इसे ठीक कर सकते हैं। इंडेक्स में फ़ील्ड को शामिल करके, क्वेरी को डेटा लोड करने की आवश्यकता नहीं है।

Answer 2

मैं कहूंगा कि अपने indexs ठीक तरह से स्थापित नहीं कर रहे हैं, आपकी दूसरी क्वेरी एक आंतरिक क्वेरी की तरह है जो प्रभावी रूप से है अगर यह समझ में आता है तो अपना आंतरिक सूचकांक समूह बनाना!