EXPLAIN के बारे मा मौन छ र यसलाई कसरी बोल्ने

क्लासिक प्रश्न जुन एक विकासकर्ताले आफ्नो DBA मा ल्याउँदछ वा व्यवसाय मालिकले PostgreSQL सल्लाहकारलाई ल्याउँछ लगभग सधैं उस्तै सुनिन्छ: "किन अनुरोधहरू डाटाबेसमा पूरा हुन यति लामो समय लाग्छ?"

कारणहरूको परम्परागत सेट:

• असक्षम एल्गोरिथ्म
  जब तपाइँ केहि दशौं हजार रेकर्डहरू मा धेरै CTE मा सामेल हुने निर्णय गर्नुहुन्छ
• अप्रासंगिक तथ्याङ्क
  यदि तालिकामा तथ्याङ्कको वास्तविक वितरण पछिल्लो पटक ANALYZE द्वारा सङ्कलन गरिएको भन्दा धेरै फरक छ भने
• स्रोतहरूमा "प्लग"
  र त्यहाँ अब CPU को पर्याप्त समर्पित कम्प्युटिङ पावर छैन, मेमोरीको गीगाबाइट लगातार पम्प भइरहेको छ, वा डिस्क डाटाबेसको सबै "चाहनाहरू" संग राख्न सक्दैन।
• अवरुद्ध प्रतिस्पर्धी प्रक्रियाबाट

र यदि ब्लकिङहरू समात्न र विश्लेषण गर्न धेरै गाह्रो छ भने, त्यसपछि हामीलाई आवश्यक सबै कुराको लागि प्रश्न योजनाप्रयोग गरेर प्राप्त गर्न सकिन्छ अपरेटर व्याख्या गर्नुहोस् (यो राम्रो छ, अवश्य पनि, तुरुन्तै व्याख्या गर्न (विश्लेषण, बफरहरू) ...) वा 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"

तर "पानाबाट" पाठमा योजना पढ्न धेरै गाह्रो र अस्पष्ट छ:

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

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

र यसको मतलब हामीलाई चाहिन्छ ...

उपकरण

यसमा हामीले योजना र अनुरोध अनुसार "कसलाई दोष दिने र के गर्ने" बुझ्न मद्दत गर्ने सबै मुख्य मेकानिकहरू सङ्कलन गर्ने प्रयास गर्यौं। ठीक छ, र समुदायसँग आफ्नो अनुभवको अंश साझा गर्नुहोस्।
भेट्नुहोस् र प्रयोग गर्नुहोस् - व्याख्या.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 समय वितरण नोड्स द्वारा:

ठीक छ, सबैभन्दा कठिन विकल्पहरूको लागि उहाँ मद्दत गर्न हतारमा हुनुहुन्छ प्रगति चार्ट:

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

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

ठिक छ, यदि योजनाको सम्पूर्ण संरचना र यसका घाउ ठाउँहरू पहिले नै राखिएका छन् र देखिने छन् भने, विकासकर्तालाई हाइलाइट गरेर "रूसी भाषा" मा व्याख्या नगर्ने?

हामीले पहिले नै दर्जनौं यस्ता सिफारिस टेम्प्लेटहरू सङ्कलन गरिसकेका छौं।

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

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

...वा यो जस्तै:

अनुरोधमा प्यारामिटरहरू प्रतिस्थापन गर्दै

यदि तपाईंले योजनाको लागि अनुरोध मात्र होइन, तर लगको DETAIL लाइनबाट यसको प्यारामिटरहरू पनि "संलग्न" गर्नुभयो भने, तपाइँ यसलाई विकल्पहरू मध्ये एकमा प्रतिलिपि गर्न सक्नुहुन्छ:

• अनुरोधमा मूल्य प्रतिस्थापनको साथ
  तपाईंको आधार र थप प्रोफाइलिङमा प्रत्यक्ष कार्यान्वयनको लागि

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

• PREPARE/EXECUTE मार्फत मूल्य प्रतिस्थापनको साथ
  अनुसूचकको काम अनुकरण गर्न, जब प्यारामेट्रिक भागलाई बेवास्ता गर्न सकिन्छ - उदाहरणका लागि, विभाजन गरिएको तालिकाहरूमा काम गर्दा

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

योजनाहरूको अभिलेख

टाँस्नुहोस्, विश्लेषण गर्नुहोस्, सहकर्मीहरूसँग साझेदारी गर्नुहोस्! योजनाहरू अभिलेखमा रहनेछन् र तपाईं पछि तिनीहरूमा फर्कन सक्नुहुन्छ: explain.tensor.ru/archive

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

निम्न लेखहरूमा म योजनाको विश्लेषण गर्दा उत्पन्न हुने कठिनाइ र निर्णयहरूको बारेमा कुरा गर्नेछु।

स्रोत: www.habr.com