🥇AÇIQLAMA nə haqqında susur və onu necə danışdırmaq olar

Bir tərtibatçının DBA-ya və ya bir iş sahibinin PostgreSQL məsləhətçisinə gətirdiyi klassik sual demək olar ki, həmişə eyni səslənir: "Niyə sorğuların verilənlər bazasında tamamlanması bu qədər uzun çəkir?"

Ənənəvi səbəblər toplusu:

səmərəsiz alqoritm
bir neçə on minlərlə qeyddən çox bir neçə CTE-yə QOŞULMAQ qərarına gəldikdə
köhnəlmiş statistika
əgər cədvəldəki məlumatların faktiki paylanması ANALYZE-in sonuncu dəfə topladığından çox fərqlidirsə
resurslara "qoşmaq"
və artıq CPU-nun kifayət qədər xüsusi hesablama gücü yoxdur, gigabayt yaddaş daim pompalanır və ya disk verilənlər bazasının bütün "istəklərini" yerinə yetirə bilmir
bloklama rəqabətli proseslərdən

Əgər bloklamaları tutmaq və təhlil etmək olduqca çətindirsə, o zaman bizə lazım olan hər şey üçün sorğu planı, istifadə edərək əldə edilə bilər EXPLAIN operatoru (Əlbətdə ki, dərhal izah etmək daha yaxşıdır (TƏHLİL, BUFER) ...) və ya auto_explain modulu.

Lakin eyni sənədlərdə deyildiyi kimi,

“Planı başa düşmək bir sənətdir və ona yiyələnmək müəyyən təcrübə tələb edir...”

Ancaq düzgün alətdən istifadə etsəniz, onsuz da edə bilərsiniz!

Sorğu planı adətən nə kimi görünür? Buna bənzər bir şey:

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

və ya bu kimi:

"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"

Ancaq planı "vərəqdən" mətndə oxumaq çox çətin və aydın deyil:

qovşaqda göstərilir subtree resursları ilə cəmi
yəni müəyyən bir nodu yerinə yetirmək üçün nə qədər vaxt lazım olduğunu və ya cədvəldəki bu oxunmanın diskdən məlumat gətirdiyini başa düşmək üçün birtəhər birini digərindən çıxarmaq lazımdır.
node vaxt lazımdır döngələrlə çoxaltmaq
bəli, çıxma "başında" edilməli olan ən mürəkkəb əməliyyat deyil - axırda icra müddəti bir düyünün bir icrası üçün orta hesabla göstərilir və yüzlərlə ola bilər.
yaxşı və bütün bunlar birlikdə bizə əsas suala cavab verməyə mane olur - bəs kim "ən zəif halqa"?

Bütün bunları bir neçə yüz inkişaf etdiricimizə izah etməyə çalışdıqda, bunun kənardan belə göründüyünü başa düşdük:

Və bu o deməkdir ki, bizə lazımdır...

Alət

Biz plana və istəyə uyğun olaraq “kimin günahkar olduğunu və nə edəcəyini” anlamağa kömək edən bütün əsas mexanizmləri toplamağa çalışdıq. Yaxşı, təcrübənizin bir hissəsini cəmiyyətlə bölüşün.
Tanış və istifadə - izah.tensor.ru

Planların görünməsi

Planı belə görünəndə başa düşmək asandır?

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

Həqiqətən deyil.

Amma belə, qısaldılmış formadaəsas göstəricilər ayrıldıqda daha aydın olur:

Ancaq plan daha mürəkkəbdirsə, o, köməyə gələcək piechart vaxt paylanması qovşaqlara görə:

Yaxşı, ən çətin variantlar üçün o, kömək etməyə tələsir tərəqqi diaqramı:

Məsələn, bir planın birdən çox həqiqi kökə malik ola biləcəyi olduqca qeyri-trivial vəziyyətlər var:

Struktur ipuçları

Yaxşı, əgər planın bütün strukturu və onun yara nöqtələri artıq tərtib edilibsə və görünürsə, niyə onları tərtibatçıya vurğulamaya və "rus dilində" izah etməyəsən?

Artıq bir neçə onlarla belə tövsiyə şablonu topladıq.

Sətir-sətir sorğu profili

İndi, orijinal sorğunu təhlil edilən planın üzərinə əlavə etsəniz, hər bir fərdi ifadəyə nə qədər vaxt sərf edildiyini görə bilərsiniz - bu kimi bir şey:

...və ya hətta belə:

Parametrlərin sorğuya dəyişdirilməsi

Yalnız plana bir sorğu deyil, həm də jurnalın DETAIL sətirindən onun parametrlərini "əlavə etmisinizsə", onu əlavə seçimlərdən birinə köçürə bilərsiniz:

sorğuda dəyər əvəzi ilə
bazanızda birbaşa icra və sonrakı profilləşdirmə üçün
```
SELECT 'const', 'param'::text;
```
PREPARE/EXECUTE vasitəsilə dəyər əvəzi ilə
planlayıcının işini təqlid etmək, parametrik hissəyə məhəl qoymamaq mümkün olduqda - məsələn, bölünmüş cədvəllər üzərində işləyərkən
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Planların arxivi

Yerləşdirin, təhlil edin, həmkarlarınızla paylaşın! Planlar arxivdə qalacaq və siz onlara daha sonra qayıda bilərsiniz: izah.tensor.ru/archive

Amma başqalarının planınızı görməsini istəmirsinizsə, “arxivdə dərc etmə” qutusunu qeyd etməyi unutmayın.

Növbəti məqalələrdə bir planı təhlil edərkən ortaya çıxan çətinliklər və qərarlar haqqında danışacağam.

Mənbə: www.habr.com

İZLƏNİN nə haqqında susur və onu necə danışdırmaq olar