क्या मैं मैसकल को ऑटो-पार्टीशन के लिए सेट कर सकता हूँ?

(यह उत्तर स्कीमा और SELECT पर निर्देशित है।)

चूंकि आप लाखों पंक्तियों का अनुमान लगाते हैं, इसलिए पहले मैं स्कीमा में कुछ सुधारों के बारे में बताना चाहता हूं।

• FLOAT(m,n) आमतौर पर ऐसा करना 'गलत' काम होता है क्योंकि इससे दो चक्कर लगते हैं। या तो सादा FLOAT का उपयोग करें (जो वोल्टेज जैसे मेट्रिक्स के लिए 'सही' लगता है) या DECIMAL(m,n) का उपयोग करें . FLOAT 4 बाइट्स है; दिए गए मामलों में, DECIMAL 3 या 4 बाइट्स होंगे।

• जब आपके पास INDEX(a) . दोनों हों और INDEX(a,b) , पूर्व अनावश्यक है क्योंकि बाद वाला ऐसे के लिए कवर कर सकता है। आपके पास 3 अनावश्यक कुंजियाँ हैं। यह धीमा कर देता है INSERTs ।

• INT(3) -- क्या आप "3-अंकीय संख्या" कह रहे हैं? यदि ऐसा है तो TINYINT UNSIGNED consider पर विचार करें (मान 0..255) INT . के बजाय 1 बाइट के लिए 4 बाइट्स के लिए। यह कई एमबी डिस्क स्थान बचाएगा, इसलिए गति। (यह भी देखें SMALLINT , आदि, और SIGNED या UNSIGNED ।)

• अगर filename बहुत बार दोहराया जाता है, आप इसे "सामान्यीकृत" करना चाह सकते हैं। इससे कई एमबी की बचत होगी।

• NOT NULL का उपयोग करें जब तक आपको NULL need की आवश्यकता न हो किसी चीज़ के लिए।

• AUTO_INCREMENT=690892041 इसका मतलब है कि आप id . के साथ आपदा के रास्ते के बारे में 1/3 हैं , जो लगभग 2 बिलियन से ऊपर होगा। क्या आप id का उपयोग करते हैं किसी भी चीज के लिए? कॉलम से छुटकारा पाने से समस्या से बचा जा सकेगा; और UNIQUE KEY बदलें करने के लिए PRIMARY KEY . (यदि आपको id की आवश्यकता है , आगे बात करते हैं।)

• ENGINE=MyISAM - स्विचिंग के कुछ प्रभाव होते हैं, अनुकूल और प्रतिकूल दोनों। टेबल 2-3 गुना बड़ी हो जाएगी। PRIMARY KEY का 'दाएं' विकल्प इस को और तेज़ कर देगा SELECT उल्लेखनीय रूप से। (और अन्य SELECTs . को धीमा कर सकता है या नहीं भी कर सकता है ।)

SELECT . पर एक नोट :चूंकि string और unit_num क्वेरी में स्थिरांक हैं, ORDER BY timestamp asc, string asc, unit_num asc के अंतिम दो क्षेत्र अनावश्यक हैं। यदि वे उन कारणों से प्रासंगिक हैं जो SELECT . में स्पष्ट नहीं हैं , तो मेरी सलाह अधूरी हो सकती है।

यह

WHERE filename = 'foobar'
  AND unit_num='40'
  AND string='2' 
  AND timestamp >= ...

INDEX(filename, unit_name, string, timestamp) . द्वारा बेहतर तरीके से नियंत्रित किया जाता है . कॉलम का क्रम महत्वपूर्ण नहीं है सिवाय वह timestamp अंतिम होना चाहिए . वर्तमान UNIQUE को पुनर्व्यवस्थित करना कुंजी, आप आपको इष्टतम अनुक्रमणिका देते हैं। (इस बीच, इसके लिए कोई भी इंडेक्स बहुत अच्छा नहीं है SELECT ।) इसे PRIMARY KEY बनाना और तालिका InnoDB इसे और भी तेज़ बना देगी।

विभाजन? कोई फायदा नहीं। प्रदर्शन के लिए नहीं; किसी और चीज के लिए नहीं जिसका आपने उल्लेख किया है। विभाजन के लिए एक सामान्य उपयोग 'पुराने' को शुद्ध करने के लिए है। अगर आप ऐसा करने का इरादा रखते हैं, तो आगे बात करते हैं।

विशाल तालिकाओं में सभी महत्वपूर्ण SELECTs को देखना सबसे अच्छा है साथ-साथ ताकि हम एक की गति न बढ़ाएँ और दूसरों की गति को गिरा दें। यह हो सकता है यहां तक ​​​​कि पता चला कि विभाजन इस तरह के ट्रेडऑफ़ में मदद करता है।