कैसे आए `wp_options` तालिका में` ऑटोलॉड` पर एक सूचकांक नहीं है?


15

वर्डप्रेस द्वारा परोसे गए प्रत्येक पृष्ठ की शुरुआत में, विकल्प लाने के लिए एक MySQL कॉल है:

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

क्योंकि autoloadस्तंभ पर कोई सूचकांक नहीं है , MySQL को सभी पंक्तियों को देखना होगा।

मुझे इस उत्तर के बारे में यह कहते हुए भी टिप्पणी मिली कि यदि कोई सूचकांक होता तो भी कोई प्रदर्शन नहीं होता।

अपने आवेदन में, मैंने सत्र प्रतिस्थापन के रूप में सेवा करने के लिए बहुत अधिक क्षणिक मूल्यों का उपयोग किया। उन्होंने बहुत अच्छा काम किया और मेरा अपना कचरा संग्रहण रूटीन है। मैंने देखा कि wp_optionsतालिका में, मेरे क्षणिक मूल्य (शुरुआत वाले _transient_) सभी हैं autoload=no। मुझे उम्मीद है कि wp_optionsसमवर्ती उपयोगकर्ता की संख्या बढ़ने पर मेरी तालिका की पंक्तियों की संख्या में वृद्धि होगी।

मैं जानना चाहता हूं कि टेबल को इस तरह क्यों बनाया गया है। और क्या मुझे अपने विशेष मामले के लिए एक सूचकांक बनाना चाहिए?

जवाबों:


11

कोई सूचकांक नहीं है क्योंकि इसकी आवश्यकता कभी भी पर्याप्त मजबूत नहीं थी।

में टिकट # 14,258 यह सुझाव दिया गया था, लेकिन जब से सबसे विकल्पों का उपयोग autoload=yesडिफ़ॉल्ट रूप से, सूचकांक वैसे भी नजरअंदाज कर दिया जाएगा।

प्रदर्शन में सहायता / सुधार के लिए wp_options को अभी भी खुले टिकट # 24044 _Add सूचकांक है

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


अपडेट नवंबर 2019

वर्डप्रेस 5.3 में सूचकांक जोड़ा गया है। आखिरकार। ऊपर उल्लिखित टिकट # 24044 और रिलीज़ के लिए डेवलपर नोट देखें

ध्यान दें कि यदि आपके पास एक ही नाम के साथ एक मौजूदा सूचकांक है, तो आपको उन्नयन के दौरान एक चेतावनी मिलेगी।

से changeset :

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


1
जहां तक ​​मैं # 24044 के माध्यम से पढ़ने से बता सकता हूं, पुराने MyISAM तालिकाओं को एक प्रदर्शन प्रतिगमन मिलेगा, नई InnoDB तालिकाओं में ज्यादातर लाभ होगा। मैं अपनी सभी विरासत तालिकाएँ InnoDB में परिवर्तित कर रहा हूं, और autoloadकॉलम पर एक इंडेक्स सेट कर रहा हूं ।
लक्रव

इतने सालों के बाद, यह अंततः वर्डप्रेस टीम द्वारा संबोधित किया गया है। इसमें एक इंडेक्स जोड़ा गया हैwp_options.autoload । स्रोत: make.wordpress.org/core/2019/10/15/… ... ... और ... core.trac.wordpress.org/ticket/24044#comment:87 ... Kudos से @DanBUK जिन्होंने यह सुविधा प्रस्तावित की थी 2013 में।
जी

धन्यवाद, @ जी, मैंने उत्तर अपडेट कर दिया है।
FUXIA

5

मैं डेबियन स्क्वीज़ बड़े उदाहरण पर 3 WP ब्लॉग चला रहा हूं और जांच कर रहा था कि mysql 200% CPU उपयोग और 3 और 6 के बीच सिस्टम लोड पर उस होस्ट पर क्यों अटका हुआ था। wp_option तालिका इस समस्या में शामिल थी इसलिए हमने इसे निष्पादित किया:

alter table wp_options add index autoload_idx(`autoload`);

इस ऑपरेशन के बाद mysql लोड जैसा कि शीर्ष में दिखाया गया है, 1% तक गिर गया है और उदाहरण लोड औसत अब 0.10 है।

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

हमारी wp_options तालिका में 347 पंक्तियाँ हैं।


2
साझा करने के लिए धन्यवाद। मुझे लगा कि वर्डप्रेस के पास इस विकल्प तालिका को संभालने में दोष है। यह इतना छोटा है, कि इसे क्वेरी नहीं किया जाना चाहिए। यह select *सभी के लिए एक बार होना चाहिए । इसके बजाय, यह प्रत्येक विकल्पों के लिए क्वेरी कर रहा है, इसीलिए एक इंडेक्स डालने से बहुत फर्क पड़ेगा।
उन्होंने

0

जबकि @fuxia ने कुछ "दावा किए गए" कारणों पर (जिनमें से अधिकांश ऑटोमैटिक के कर्मचारियों द्वारा विभिन्न Trac टिकटों आदि पर दावा किया गया था) पर स्वीकृत टच को स्वीकार किया है, वर्डप्रेस कोर का अंतर्निहित कारणwp_options तालिका के भीतर ऑटोलॉड विकल्पों के लिए एक सूचकांक शामिल नहीं है। ऑटोमैटिक ने चिंतित होकर MySQL डेटाबेस के प्रदर्शन को नकारात्मक रूप से प्रभावित किया जो अभी भी MyISAM इंजन का उपयोग कर रहे थे।

विशेष रूप से, उन्होंने खुद को WordPress.org वेबसाइट की ओर इशारा किया, एक बहुत पुराना / जटिल डेटाबेस होने के नाते, एक उदाहरण वेबसाइट के रूप में जिसका प्रदर्शन इस तरह के सूचकांक से आहत होगा।

लगभग सभी पिछले 9 साल के लिए सूचकांक नहीं जोड़ने के लिए अन्य कारणों से (Trac टिकट के मामले में हाँ, 2010 के बाद से # 14,258 और 2013 के Trac टिकट मामले में के बाद से # 24,044 ) बार-बार गलत के सदस्यों के दर्जनों द्वारा सिद्ध किया गया वर्डप्रेस समुदाय, फिर भी ऑटोमैटिक कर्मचारियों ने कई स्वतंत्र बेंचमार्क परीक्षणों को बार-बार अनदेखा किया और वापस MyISAM चिंताओं का उल्लेख किया।

शुक्र है कि PHP 7.2 के साथ 2019 के अंत में वर्डप्रेस कोर द्वारा अनुशंसित "डिफ़ॉल्ट" संस्करण, और InnoDB इंजन के साथ अब 5.5 के बाद MySQL के संस्करणों में डिफ़ॉल्ट है , और @DanBUK सहित विभिन्न डेवलपर्स के निरंतर दबाव के साथ जो वर्षों से इस मुद्दे पर बने रहे। , ऑटोमैटिक ने आखिरकार दिया और नवंबर 2019 में वर्डप्रेस 5.3+ के रूप में ऑटोलॉड इंडेक्स जोड़ने का फैसला किया।

हम लिटिलबीज़ी ने पहला ज्ञात प्लगइन लॉन्च किया था जो स्वचालित रूप से सूचकांक को जोड़ देता था यदि यह मौजूद नहीं था, जो अभी भी गिटहब पर उपलब्ध है और नियमित रूप से डाउनलोड किया जा रहा है। कृपया ध्यान दें कि यदि आप WP Core 5.3 + चला रहे हैं, तो आपको अपने WordPress स्टैक में ऐसे प्लग इन को इंस्टॉल करने की आवश्यकता नहीं है ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.