🥇एक्सप्लेन किस बारे में चुप है और उससे बात कैसे करवाएं

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

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

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

और यदि अवरोधों को पकड़ना और उनका विश्लेषण करना काफी कठिन है, तो बाकी सभी चीजों के लिए हमें इसकी आवश्यकता है पूछताछ योजना, जिसका उपयोग करके प्राप्त किया जा सकता है ऑपरेटर को समझाएं (निःसंदेह, तुरंत व्याख्या करना (विश्लेषण करना, बफर करना) बेहतर है...) या ऑटो_एक्सप्लेन मॉड्यूल.

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

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

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

एक क्वेरी योजना आम तौर पर कैसी दिखती है? ऐसा कुछ:

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"

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

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

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

और इसका मतलब है कि हमें चाहिए...

उपकरण

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

योजनाओं की दृश्यता

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

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

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

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

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

खैर, सबसे कठिन विकल्पों के लिए वह मदद करने की जल्दी में है प्रगति चार्ट:

उदाहरण के लिए, ऐसी बहुत ही गैर-मामूली स्थितियाँ होती हैं जब किसी योजना में एक से अधिक वास्तविक रूट हो सकते हैं:

संरचनात्मक सुराग

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

हमने पहले ही ऐसे कुछ दर्जन अनुशंसा टेम्पलेट एकत्र कर लिए हैं।

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

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

...या इस तरह भी:

अनुरोध में पैरामीटर प्रतिस्थापित करना

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

अनुरोध में मूल्य प्रतिस्थापन के साथ
आपके आधार पर सीधे निष्पादन और आगे की प्रोफाइलिंग के लिए
```
SELECT 'const', 'param'::text;
```
PREPARE/EXECUTE के माध्यम से मूल्य प्रतिस्थापन के साथ
शेड्यूलर के कार्य का अनुकरण करने के लिए, जब पैरामीट्रिक भाग को अनदेखा किया जा सकता है - उदाहरण के लिए, विभाजित तालिकाओं पर काम करते समय
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

योजनाओं का पुरालेख

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

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

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

स्रोत: www.habr.com

EXPLAIN किस बारे में चुप है और इसे कैसे बोलना है