MySQL अनुकूलक मुद्दों

क्या मैं इसके विकास के कई वर्षों के लिए MySQL के बारे में समझने में कामयाब रहा:

• पिछड़े अनुकूलता को तोड़े बिना विकास असंभव है
• टूटी हुई पिछड़ी संगतता के साथ किसी को भी MySQL की आवश्यकता नहीं है।

मैं दो गंभीर MySQL डीएनए समस्याओं का वर्णन करूंगा जो किसी भी MySQL 5.1 और 5.5 उपयोगकर्ता अप्रत्यक्ष रूप से सामना करते हैं (मैंने 5.6 के बारे में परीक्षण नहीं किया है, लेकिन मुझे नहीं लगता कि यह पल बदल गया है)।

MySQL आखिर कैसे काम करता है?

वहाँ MySQL ही है - यह

• पार्सर
• क्वेरी ऑप्टिमाइज़र
• प्रतिकृति
• सिस्टम कैटलॉग

अन्य चीजें हैं, लेकिन ये मुख्य हैं।

एक भंडारण इंजन है: एक प्लगइन जो निम्नलिखित कार्यक्षमता को लागू करता है:

• लेन-देन
• डिस्क पर भंडारण की मेज
• सूचकांक
• आंकड़े

सूची संपूर्ण नहीं है, और यह बहुत सही ढंग से जिम्मेदारियों में विभाजित नहीं है, लेकिन हमारे विचार से यह संतोषजनक है।

स्टोरेज इंजन एपीआई एक ऐसी पवित्र गाय है जिसे आप छू नहीं सकते।
मैं एक अद्भुत, अद्भुत उदाहरण देना चाहता हूं कि यह स्टोरेज इंजन एपीआई "पूरी तरह से" कैसे बनाया गया है और इसके साथ क्या समस्याएं हैं।

मैंने इस बग के साथ संघर्ष करते हुए इन समस्याओं का विशेष रूप से अध्ययन किया: बग्सस्मिस्क्ला .bug.php ? id=63320
अगर किसी को बग और स्रोत कोड दोनों को समझने की ताकत और इच्छा महसूस होती है, तो मैं आपको शुभकामनाएं दे सकता हूं।
जो लोग आलसी हैं और मेरी कहानी पर भरोसा करते हैं वे सिर्फ पढ़ सकते हैं।

तो, स्टोरेज इंजन क्या सूचना ऑप्टिमाइज़र को रिपोर्ट / दे सकता है?

• तालिका में अभिलेखों की संख्या (इसे पंक्तिबद्ध करें)
• पूर्णांक मान पंक्तियों_पेर_की (संख्या के अनुसार__प्रतिकारकों की संख्या_अंक_प्रतिष्ठित_रूपों की संख्या)।

कृपया ध्यान दें - अद्वितीय प्रविष्टियों की संख्या को सीधे मान्यता नहीं दी जा सकती है।
MySQL इसे तालिका में पंक्तियों / रो_पर_की संख्या के रूप में मानता है

हम इसे कोड के रूप में लिखते हैं (परिणाम के रूप में इसकी गणना कैसे की जाती है):

int unique_row_count_mysql = row_count / rows_per_key; int rows_per_key = row_count / unique_row_count_engine; int unique_row_count_mysql = row_count / ((int) (row_count / unique_row_count_engine)); 

मैं समझाता हूं:

 a2 = (int)b / ((int) (b / a)); 

बस इस फ़ंक्शन की कमी के कारण, हम लगातार दो बार संख्या में चक्कर काटते हैं।
मैं एक उदाहरण समझाता हूँ। आज्ञा दें कि एक तालिका एक लाख रिकॉर्ड के साथ हो।
अद्वितीय कुंजियों की एक अलग संख्या पर विचार करें।

कुल रिकॉर्ड	अनोखी प्रविष्टियाँ	rows_per_key	अद्वितीय प्रविष्टियां (अनुकूलक के अनुसार)
1000000	100000	10	100000
1000000	200000	5	200000
1000000	300000	3	333333
1000000	400000	2	500000
1000000	500000	2	500000
1000000	600000	1	1000000
1000000	700000	1	1000000
1000000	800000	1	1000000
1000000	900000	1	1000000
1000000	1000000	1	1000000

क्या आपको यह पसंद है?
संग्रहण इंजन API की सटीकता को खोने का कोई कारण नहीं है।
आप एपीआई को नहीं छू सकते।
यह समस्या किसी भी संग्रहण इंजन पर लागू होती है।

यह आधी लड़ाई है। हम और आगे जा रहे हैं।
एक प्रभावी योजना का चयन करने के लिए, ऑप्टिमाइज़र को अद्वितीय रिकॉर्ड और कुल रिकॉर्ड की संख्या जानने की आवश्यकता नहीं है।
अक्सर * उसे NULLs की संख्या, गैर-NULLs की संख्या, समग्र कुंजियों के मामले में - विभिन्न संयोजनों को जानना होगा।
अक्सर - यह निम्नलिखित मामलों में है:

• इनर जॉइन ("सिंपल" जॉइन)
• बाहरी जुड़ाव (बाएं / दाएं / पूर्ण)
• उपशम (/ in / not / all / any / मौजूद / मौजूद नहीं है)

नल पर आंकड़े होने से, आप विभिन्न प्रभावी अनुकूलन बना सकते हैं।
इसके बारे में थोड़ी देर बाद, पहले हम समस्या का वर्णन करते हैं।

स्टोरेज इंजन एपीआई में, अन्य प्रविष्टियों से नल को अलग करने की कोई _ क्षमता नहीं है।
लगभग नहीं।
InnoDB और MyISAM दो वैश्विक चर लागू करते हैं: innodb_stats_method और myisam_stats_method।
इन वैश्विक चर के निम्नलिखित अर्थ हैं:

• अशक्त उपेक्षा करते हैं
• नल बराबर
• अशक्त न के बराबर।

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

यह बुरा क्यों है?
यहाँ एक सरल अनुरोध है:

  a.id = b.id पर join b से * का चयन करें 

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

एक और अनुरोध

  a .id = b.id पर बाईं ओर से b चुनें 

यदि यह शून्य नहीं के बराबर है - सब कुछ ठीक है
यदि यह नल समान है या नल अनदेखा करते हैं - सब कुछ बहुत खराब है, तो ऑप्टिमाइज़र एक आशावादी योजना का चयन करेगा - यह मानते हुए कि शामिल होने के आउटपुट पर कुछ रिकॉर्ड होंगे।

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

मेरे दृष्टिकोण से - यह एक मृत मुर्गी है।
एएसटी (अमूर्त सिंटैक्स ट्री) के शीर्ष पर निर्मित MySQL अनुकूलक मृत है, इसे विकसित और सुधार नहीं किया जा सकता है। यह एक बहुत बड़ा छेद है जो बहुत समय बर्बाद करता है और क्वेरी प्रदर्शन में सुधार करने का अवसर प्रदान नहीं करता है।

संग्रहण इंजन स्वयं तेज़ है, लेकिन ऑप्टिमाइज़र उनका उपयोग करने में सक्षम नहीं है। कोई एपीआई, कोई सुविधा नहीं, कोई सामान्य आँकड़े नहीं।

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