क्या EXPLAIN इसके बारे में चुप है और इसके बारे में कैसे बात करें

एक क्लासिक सवाल जो एक डेवलपर अपने डीबीए या एक व्यवसाय के मालिक, एक पोस्टग्रेक्सेल कंसल्टेंट के पास आता है, लगभग हमेशा एक ही लगता है: "इतने लंबे समय तक डेटाबेस पर प्रश्न क्यों चलते हैं?"

कारणों का पारंपरिक सेट:

• अक्षम एल्गोरिथ्म
  जब आपने हज़ारों रिकॉर्ड के एक जोड़े के लिए कई सीटीई का एक जिन्न बनाने का फैसला किया
• अप्रासंगिक आँकड़े
  यदि तालिका में वास्तविक डेटा वितरण पहले से ही अलग है तो ANALYZE ने इसे एकत्र किया
• संसाधनों द्वारा "गैग"
  और पहले से ही सीपीयू की पर्याप्त समर्पित कंप्यूटिंग शक्ति नहीं है, स्मृति के गीगाबाइट लगातार पंप होते हैं या डिस्क सभी डेटाबेस "विशलिस्ट" के साथ नहीं रहती है
• प्रतिस्पर्धी प्रक्रियाओं से अवरुद्ध

और अगर ताले को पकड़ना और विश्लेषण करना काफी मुश्किल है, तो बाकी सब चीजों के लिए, हमें एक क्वेरी प्लान की आवश्यकता होती है, जिसे EXPLAIN ऑपरेटर ( बेहतर, निश्चित रूप से, तुरंत EXPLAIN (ANALYZE, BUFFERS) ... ) या auto_explain मॉड्यूल का उपयोग करके प्राप्त किया जा सकता है।

लेकिन, जैसा कि एक ही दस्तावेज में कहा गया है,

"योजना को समझना एक कला है, और इसमें महारत हासिल करने के लिए आपको कुछ अनुभव की आवश्यकता होती है, ..."

लेकिन आप इसके बिना कर सकते हैं, अगर आप सही उपकरण का उपयोग करते हैं!

क्वेरी प्लान आमतौर पर कैसा दिखता है? कुछ इस तरह:

Index Scan using pg_class_relname_nsp_index on pg_class (actual time=0.049..0.050 rows=1 loops=1) Index Cond: (relname = $1) Filter: (oid = $0) Buffers: shared hit=4 InitPlan 1 (returns $0,$1) -> Limit (actual time=0.019..0.020 rows=1 loops=1) Buffers: shared hit=1 -> Seq Scan on pg_class pg_class_1 (actual time=0.015..0.015 rows=1 loops=1) Filter: (relkind = 'r'::"char") Rows Removed by Filter: 5 Buffers: shared hit=1 

या इस तरह:

 "Append (cost=868.60..878.95 rows=2 width=233) (actual time=0.024..0.144 rows=2 loops=1)" " Buffers: shared hit=3" " CTE cl" " -> Seq Scan on pg_class (cost=0.00..868.60 rows=9972 width=537) (actual time=0.016..0.042 rows=101 loops=1)" " Buffers: shared hit=3" " -> Limit (cost=0.00..0.10 rows=1 width=233) (actual time=0.023..0.024 rows=1 loops=1)" " Buffers: shared hit=1" " -> CTE Scan on cl (cost=0.00..997.20 rows=9972 width=233) (actual time=0.021..0.021 rows=1 loops=1)" " Buffers: shared hit=1" " -> Limit (cost=10.00..10.10 rows=1 width=233) (actual time=0.117..0.118 rows=1 loops=1)" " Buffers: shared hit=2" " -> CTE Scan on cl cl_1 (cost=0.00..997.20 rows=9972 width=233) (actual time=0.001..0.104 rows=101 loops=1)" " Buffers: shared hit=2" "Planning Time: 0.634 ms" "Execution Time: 0.248 ms" 

लेकिन "शीट से" पाठ के साथ योजना को पढ़ना बहुत मुश्किल और प्रिय है:

• नोड सबट्री संसाधनों का योग प्रदर्शित करता है
  यह समझने के लिए कि किसी विशेष नोड को निष्पादित करने में कितना समय लगा, या वास्तव में डिस्क से डेटा उठाया तालिका से कितना पढ़ने में - आपको किसी तरह एक को दूसरे से घटाना होगा
• नोड समय को छोरों से गुणा किया जाना चाहिए
  हां, घटाव सबसे कठिन ऑपरेशन नहीं है जिसे "दिमाग में" करने की आवश्यकता है - आखिरकार, रनटाइम को नोड के एक निष्पादन पर औसतन इंगित किया जाता है, और उनमें से सैकड़ों हो सकते हैं
• अच्छी तरह से, और यह सब मिलकर मुख्य प्रश्न का उत्तर देना मुश्किल बनाता है - तो "सबसे कमजोर कड़ी" कौन है?

जब हमने अपने डेवलपर्स के कई सौ लोगों को यह सब समझाने की कोशिश की, तो हमने महसूस किया कि बाहर से यह कुछ इस तरह दिखता है:



और इसका मतलब है कि हमें ज़रूरत है ...

साधन

इसमें, हमने सभी प्रमुख मैकेनिकों को इकट्ठा करने की कोशिश की जो योजना के अनुसार मदद करते हैं और यह समझने के लिए अनुरोध करते हैं कि "किसे दोष देना है और क्या करना है।" खैर, अपने कुछ अनुभव समुदाय के साथ साझा करें।
मिलते हैं और उपयोग करते हैं - Explan.tensor.ru

स्पष्ट योजनाएँ

क्या एक योजना को समझना आसान है जब यह इस तरह दिखता है?

 Seq Scan on pg_class (actual time=0.009..1.304 rows=6609 loops=1) Buffers: shared hit=263 Planning Time: 0.108 ms Execution Time: 1.800 ms 

वास्तव में नहीं।

लेकिन इस तरह, संक्षिप्त रूप में , जब कुंजी संकेतक अलग हो जाते हैं - यह पहले से ही बहुत स्पष्ट है:



लेकिन यदि योजना अधिक जटिल है, तो नोड्स द्वारा piechart समय वितरण बचाव में आएगा:



सबसे कठिन विकल्पों में से, निष्पादन आरेख मदद के लिए देता है:



उदाहरण के लिए, काफी गैर-तुच्छ परिस्थितियां हैं जब एक योजना में एक से अधिक वास्तविक जड़ें हो सकती हैं:

स्ट्रक्चरल टिप्स

ठीक है, और अगर योजना की पूरी संरचना और इसके गले में धब्बे पहले से ही दिखाई देते हैं और दिखाई देते हैं - तो उन्हें डेवलपर के साथ उजागर क्यों न करें और उन्हें "रूसी भाषा" के साथ समझाएं?

हम पहले से ही इस तरह के एक दर्जन से अधिक सिफारिशें एकत्र कर चुके हैं।

क्वेरी प्रोफाइलर

अब, यदि आप मूल क्वेरी को विश्लेषण की गई योजना पर रखते हैं, तो आप देख सकते हैं कि प्रत्येक व्यक्तिगत ऑपरेटर को कितना समय लगा - ऐसा कुछ:



... या यहां तक ​​कि:

अनुरोध में मापदंडों का प्रतिस्थापन

यदि आप "संलग्न" न केवल योजना के लिए अनुरोध करते हैं, बल्कि लॉग के डीटेल लाइन से इसके पैरामीटर भी हैं, तो आप इसे विकल्पों में से एक में कॉपी कर सकते हैं:

• अनुरोध में मूल्यों के प्रतिस्थापन के साथ
  इसके आधार पर प्रत्यक्ष निष्पादन और आगे की रूपरेखा के लिए
  
  

   SELECT 'const', 'param'::text; 

• PREPARE / EXECUTE के माध्यम से मूल्य प्रतिस्थापन के साथ
  जब पैरामीट्रिक भाग को नजरअंदाज किया जा सकता है - शेड्यूलर के काम का अनुकरण करने के लिए - उदाहरण के लिए, जब विभाजित तालिकाओं पर काम कर रहे हों
  
  

   DEALLOCATE ALL; PREPARE q(text) AS SELECT 'const', $1::text; EXECUTE q('param'::text); 

पुरालेख

सम्मिलित करें, विश्लेषण करें, सहकर्मियों के साथ साझा करें! योजनाएं संग्रह में रहेंगी, और आप बाद में उन पर वापस लौट सकते हैं: Explain.tensor.ru/archive

लेकिन अगर आप दूसरों को अपनी योजना नहीं देखना चाहते हैं, तो "संग्रह में प्रकाशित न करें" चेकबॉक्स की जांच करना न भूलें।

निम्नलिखित लेखों में मैं योजना के विश्लेषण में आने वाली कठिनाइयों और समाधानों के बारे में बात करूंगा।