6

मैं एक MySQL डेटाबेस बना रहा हूं जिसमें खमीर की प्रजातियों में डीएनए के विशेष सबस्ट्रिंग्स के बारे में प्रविष्टियां हैं। मेरी तालिका इस तरह दिखती है:टेक्स्ट फ़ील्ड पर COUNT और GROUP धीमा लगता है

+--------------+---------+------+-----+---------+-------+ 
| Field  | Type | Null | Key | Default | Extra | 
+--------------+---------+------+-----+---------+-------+ 
| species  | text | YES | MUL | NULL |  | 
| region  | text | YES | MUL | NULL |  | 
| gene   | text | YES | MUL | NULL |  | 
| startPos  | int(11) | YES |  | NULL |  | 
| repeatLength | int(11) | YES |  | NULL |  | 
| coreLength | int(11) | YES |  | NULL |  | 
| sequence  | text | YES | MUL | NULL |  | 
+--------------+---------+------+-----+---------+-------+ 

लगभग 1.8 मिलियन रिकॉर्ड हैं। क्वेरी का एक प्रकार में मैं यह देखने के लिए कि कितने डीएनए सबस्ट्रिंग प्रजातियों और क्षेत्र के प्रत्येक प्रकार के साथ जुड़े रहे हैं चाहते हैं, तो मैं इस क्वेरी जारी करते हैं:

select species, region, count(*) group by species, region; 

प्रजातियों और क्षेत्र स्तंभ केवल दो संभव प्रविष्टियाँ (संरक्षित/scer प्रजातियों के लिए, और क्षेत्र के लिए प्रमोटर/कोडिंग) अभी तक यह प्रश्न लगभग 30 सेकंड लेता है।

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

क्षमा करें अगर यह एक हड्डी का सवाल है, तो मैं एक एसक्यूएल neophyte हूँ।

पीएस मैंने this question भी देखा है लेकिन प्रस्तावित समाधान जो मैं कर रहा हूं उसके लिए प्रासंगिक प्रतीत नहीं होता है।

संपादित करें: उन क्षेत्रों को VARCHARs में कनवर्ट करना रनटाइम को ~ 2.5 सेकंड तक कम कर देता है। नोट मैंने इसे ईएनई के खिलाफ भी समय दिया, जिसमें एक समान समय था।

+0

आपकी प्राथमिक कुंजी कौन सा फ़ील्ड है? –

+0

मेरे पास प्राथमिक कुंजी नहीं है। मैं कृत्रिम रूप से एक बना सकता हूं, लेकिन क्या इससे कोई फर्क पड़ता है? – Rich

उत्तर

6

आपके सभी स्ट्रिंग आधारित कॉलम टेक्स्ट के रूप में परिभाषित क्यों हैं? यदि आप प्रदर्शन तुलना को पढ़ते हैं, तो आप देखेंगे कि टेक्स्ट इंडेक्सिंग का उपयोग करके VARCHAR कॉलम से ~ 3x धीमी थी: http://forums.mysql.com/read.php?24,105964,105964

+0

अच्छी पकड़। ध्यान नहीं दिया कि वे 'टेक्स्ट' थे। –

+0

मैंने टेक्स्ट किया क्योंकि एक सहकर्मी मेरा कहना है कि उस और वचरर के बीच कोई अंतर नहीं होगा। :) एक वर्चर का उपयोग करके मेरा रनटाइम 33 सेकंड से 2.5 हो गया। – Rich

+0

@Rich: वाह - इस तरह के नाटकीय अंतर की उम्मीद नहीं कर रहा था। अगर आप कम हो सकते हैं तो आप कम हो सकते हैं प्रजातियों और क्षेत्र के स्तंभों को अपने संबंधित मूल्यों को रखने वाली टेबलों के लिए विदेशी कुंजी होने के लिए बदल दिया। एक आईएनटी हमेशा 4 बाइट्स होता है, जबकि एक वर्चर (4) 5 होता है, तो आप कल्पना कर सकते हैं कि कितने बाइट्स वचर (100) हैं। –

3

यदि आपके फ़ील्ड में केवल 2 मान होने वाले हैं, तो आप उन्हें बूलियन बनाने से बहुत बेहतर हैं। आपको NOT NULL सबकुछ भी बनाना चाहिए जब तक कि वास्तविक कारण न हो, आपको NULL होने की आवश्यकता होगी।

कॉलम के लिए मानव-पठनीय मूल्यों की सीमित संख्या का उपयोग करने के बेहतर तरीके के लिए ENUM type पर भी एक नज़र डालें।

धीमे होने के लिए, कोशिश करने वाली पहली बात यह है कि आप अपने कॉलम पर इंडेक्स बनाएं।

create index on mytablename (species, region); 

यह करना चाहिए: विशेष क्वेरी आप यहाँ दिखा रहे हैं के लिए, species, region पर एक सूचकांक एक बड़ा फर्क करना चाहिए।

+2

क्या आप वाकई इस तरह के कम-कार्डिनालिटी डेटा के साथ एक बड़ा अंतर डालेंगे? –

+1

नहीं, मुझे यकीन नहीं है, लेकिन मुझे लगता है कि यह एक अच्छा अनुमान है। मैंने 'एक्स्पलाइन' का उपयोग करने के बारे में कुछ लिखना शुरू किया, लेकिन यह कीड़े के एक कैन में बदलना शुरू कर दिया। और मैंने अनुमान लगाया कि अंतिम परिणाम शायद यह होगा कि हमें किसी भी तरह का इंडेक्स बनाने का प्रयास करना चाहिए। – Vineet

+0

मैंने इंडेक्स की कोशिश की, लेकिन इससे कोई फर्क नहीं पड़ता। मैंने VARCHAR को भी ओएमजी टट्टू के रूप में सुझाव दिया कि यह बहुत तेज़ था। इसके बाद मैंने वारार्स से कोई ध्यान देने योग्य गति के साथ enums के खिलाफ कोशिश की। – Rich

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