एक टाइमस्टैम्प पर एक सूचकांक बनाया जा रहा है क्वेरी

Question

अनुकूलन करने के लिए मैं निम्नलिखित फार्म के एक प्रश्न है:

SELECT * FROM MyTable WHERE Timestamp > [SomeTime] AND Timestamp < [SomeOtherTime] 

मैं इस क्वेरी अनुकूलन करना चाहते हैं, और मैं टाइमस्टैम्प पर एक सूचकांक लगाने के बारे में सोच रहा हूँ, लेकिन नहीं कर रहा हूँ यकीन है कि यह मदद करेगा। आदर्श रूप में मैं टाइमस्टैम्प को क्लस्टर्ड इंडेक्स बनाना चाहता हूं, लेकिन MySQL प्राथमिक कुंजी को छोड़कर क्लस्टर इंडेक्स का समर्थन नहीं करता है।

• MyTable में 4 मिलियन + पंक्तियां हैं।
• Timestamp वास्तव में INT प्रकार का है।
• एक बार एक पंक्ति सम्मिलित की गई है, यह कभी नहीं बदला गया है।
• किसी भी Timestamp वाली पंक्तियों की संख्या 20 के बारे में औसत पर है, लेकिन हो सकता है के रूप में उच्च के रूप में 200 के
• नव डाला पंक्तियों एक Timestamp कि मौजूदा पंक्तियों की तुलना में सबसे अधिक है है, लेकिन कुछ की तुलना में कम हो सकता है हाल की पंक्तियों में से।

Timestamp पर एक सूचकांक मुझे इस प्रश्न को अनुकूलित करने में मदद करेगा?

Answer 1

इसके बारे में कोई सवाल नहीं है। इंडेक्स के बिना, आपकी क्वेरी को तालिका में प्रत्येक पंक्ति को देखना होगा। इंडेक्स के साथ, सही पंक्तियों का पता लगाने के लिए क्वेरी बहुत तात्कालिक हो जाएगी। कीमत है जो आप भुगतान करेंगे आवेषण में एक मामूली प्रदर्शन कमी है, लेकिन वह वास्तव में मामूली होगा।

Answer 2

आप निश्चित रूप से एक सूचकांक का उपयोग करना चाहिए। MySQL कोई सुराग नहीं क्या आदेश उन timestamps में हैं, और किसी निश्चित टाइमस्टैम्प (या टाइमस्टैम्प रेंज) के लिए एक रिकॉर्ड को खोजने के लिए यह हर एक रिकॉर्ड के माध्यम से देखने के लिए की जरूरत है में है। और उनमें से 4 मिलियन के साथ, यह काफी समय है! इंडेक्स अपने डेटा के बारे MySQL बताने का अपना तरीका है - "। मैं अक्सर इस क्षेत्र को देखो, तो मैं कहाँ प्रत्येक मान के लिए रिकॉर्ड मिल सकता है की एक सूची रखने के लिए जा रहा हूँ"

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

Answer 3

आपके प्रश्नों मुख्य रूप से इस टाइमस्टैम्प का उपयोग कर रहे हैं, तो आप इस डिजाइन का परीक्षण कर सकता है (पहले भाग के रूप में टाइमस्टैम्प के साथ प्राथमिक कुंजी के विस्तार):

CREATE TABLE perf (
    , ts INT NOT NULL 
    , oldPK 
    , ... other columns 
, PRIMARY KEY(ts, oldPK) 
, UNIQUE (oldPK) 
) ENGINE=InnoDB ; 

यह सुनिश्चित होगा कि एक आप इच्छा पोस्ट की तरह प्रश्नों क्लस्टर (प्राथमिक) कुंजी का उपयोग कर रहे हैं।

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

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

पुराना पीके अभी भी UNIQUE बाधा डालकर पंक्तियों की पहचान करने के लिए उपयोग किया जा सकता है।

---

तुम भी, एक MySQL (और खुला स्रोत) वेरिएंट कि multiple clustered indices की अनुमति देता है TokuDB पर एक नजर है कर सकते हैं।

Answer 4

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

उदाहरण के लिए, यदि आप timestamp, category, और userId के साथ एक मेज है, यह बेहतर बजाय userId पर एक सूचकांक बनाने के लिए हो सकता है। कई अलग-अलग उपयोगकर्ताओं के साथ एक टेबल में यह टाइमस्टैम्प को खोजने के लिए शेष सेट को काफी कम कर देगा।

... और यदि मुझे गलत नहीं लगता है, तो इसका लाभ प्रत्येक प्रविष्टि पर टाइमस्टैम्प इंडेक्स बनाने के ऊपरी हिस्से से बचने के लिए होगा - उच्च प्रविष्टि दरों वाली तालिका में और अत्यधिक अद्वितीय टाइमस्टैम्प यह एक हो सकता है महत्वपूर्ण विचार

मैं टाइमस्टैम्प और अन्य कुंजियों के आधार पर अनुक्रमण की एक ही समस्या के साथ संघर्ष कर रहा हूं। मेरे पास अभी भी ऐसा करने का परीक्षण है, इसलिए मैं यहां जो कुछ कहता हूं उसके पीछे सबूत डाल सकता हूं। मैं अपने परिणामों के आधार पर पोस्टबैक करने की कोशिश करूंगा।

बेहतर विवरण के लिए एक परिदृश्य:

1. टाइमस्टैम्प 99% अद्वितीय
2. userId 80% अद्वितीय

3. श्रेणी 25% टाइमस्टैम्प पर अद्वितीय

   • अनुक्रमण जल्दी करने के लिए क्वेरी परिणाम कम हो जाएगा 1% तालिका आकार
   • उपयोगकर्ता आईडी पर अनुक्रमण करना जल्दी से क्वेरी परिणामों को कम करेगा 2 0% तालिका आकार
   श्रेणी जल्दी से टाइमस्टैम्प सूचक के साथ 75% तालिका आकार
   • प्रविष्टि के लिए क्वेरी परिणाम कम हो जाएगा पर
   • अनुक्रमण हमारे ज्ञान के बावजूद उच्च भूमि के ऊपर **
   • होगा कि हमारे सम्मिलन के तथ्य का सम्मान करेंगे टाइमस्टैम्प में वृद्धि हुई है, मुझे incremental कुंजी के आधार पर MySQL अनुकूलन की कोई चर्चा नहीं दिखाई दे रही है।
   • उपयोगकर्ता आईडी पर इंडेक्स के साथ सम्मिलन उचित रूप से उच्च ओवरहेड होगा।
   • श्रेणी पर इंडेक्स के साथ सम्मिलन में काफी कम ओवरहेड होगा।

** मैं माफी चाहता हूँ, मैं भूमि के ऊपर या प्रविष्टि अनुक्रमण के साथ गणना की पता नहीं है।