🥇Amiről EXPLAIN hallgat, és hogyan lehet rávenni, hogy beszéljen

A klasszikus kérdés, amelyet egy fejlesztő a DBA-jának, vagy egy üzlettulajdonos a PostgreSQL-tanácsadónak tesz fel, szinte mindig ugyanúgy hangzik: „Miért tart ilyen sokáig a kérések teljesítése az adatbázisban?”

Hagyományos okkészlet:

nem hatékony algoritmus
amikor úgy dönt, hogy CSATLAKOZZ több CTE-hez több tízezer rekordon keresztül
irreleváns statisztikák
ha a táblázatban szereplő adatok tényleges eloszlása már nagyon eltér az ANALYZE által legutóbb gyűjtötttől
"csatlakoztassa" az erőforrásokat
és már nincs elég dedikált számítási teljesítmény a CPU-ban, folyamatosan gigabájt memóriát pumpálnak, vagy a lemez nem tud lépést tartani az adatbázis minden „kívánásával”
blokkolás versengő folyamatoktól

És ha a blokkolásokat meglehetősen nehéz elkapni és elemezni, akkor minden máshoz, amire szükségünk van lekérdezési tervsegítségével szerezhető be EXPLAIN operátor (Természetesen jobb, ha azonnal MAGYARÁZNI (ELEMZÉS, PUFFEREK) ...), vagy auto_explain modul.

De amint az ugyanabban a dokumentációban szerepel,

„Egy tervet megérteni művészet, és ennek elsajátítása bizonyos mennyiségű tapasztalatot igényel...”

De nélküle is megteheti, ha megfelelő eszközt használ!

Hogyan néz ki általában egy lekérdezési terv? Valami hasonló:

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

vagy így:

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

De a terv szöveges „lapról” elolvasása nagyon nehéz és nem egyértelmű:

megjelenik a csomópontban részfa erőforrások összege
vagyis ahhoz, hogy megértsük, mennyi időbe telt egy adott csomópont végrehajtása, vagy hogy pontosan mennyit hozott a táblából a leolvasás a lemezről, valahogyan ki kell vonni az egyiket a másikból.
csomóponti időre van szükség hurokkal szorozni
igen, a kivonás nem a legbonyolultabb művelet, amelyet „fejben” kell elvégezni - elvégre a végrehajtási idő átlagosnak van megadva egy csomópont egy végrehajtásához, és több száz is lehet
nos, és mindez együtt megakadályozza, hogy megválaszoljuk a fő kérdést – hát ki "a leggyengébb láncszem"?

Amikor megpróbáltuk mindezt elmagyarázni több száz fejlesztőnknek, rájöttünk, hogy kívülről ez valahogy így néz ki:

És ez azt jelenti, hogy szükségünk van...

szerszám

Ebben megpróbáltuk összegyűjteni az összes kulcsfontosságú mechanikát, amely segít megérteni, hogy „ki a hibás és mit kell tenni” a tervnek és kérésnek megfelelően. Nos, és oszd meg tapasztalataid egy részét a közösséggel.
Ismerje meg és használja - magyarázat.tensor.ru

A tervek láthatósága

Könnyű megérteni a tervet, ha így néz ki?

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

Nem igazán.

De így, rövidített formábanha a fő mutatókat elkülönítjük, sokkal világosabb:

De ha a terv bonyolultabb, ő jön a megmentésére kördiagram időeloszlás csomópontok szerint:

Nos, a legnehezebb megoldásoknál siet a segítségére haladás diagram:

Például vannak olyan nem triviális helyzetek, amikor egy tervnek egynél több tényleges gyökere lehet:

Strukturális nyomok

Nos, ha a terv teljes szerkezete és fájó pontjai már ki vannak rakva és láthatóak, miért ne emelné ki a fejlesztőnek és magyarázná el „orosz nyelven”?

Összegyűjtöttünk már pár tucat ilyen ajánlósablont.

Soronkénti lekérdezésprofil

Most, ha az eredeti lekérdezést ráhelyezi az elemzett tervre, láthatja, hogy mennyi időt fordítottak az egyes utasításokra – ilyesmi:

...vagy akár így:

Paraméterek behelyettesítése kérésbe

Ha nem csak kérést „csatolt” a tervhez, hanem annak paramétereit is a napló RÉSZLETES sorából, akkor azt az alábbi lehetőségek egyikében is átmásolhatja:

értékhelyettesítéssel a kérésben
az Ön bázisán történő közvetlen végrehajtáshoz és további profilalkotáshoz
```
SELECT 'const', 'param'::text;
```
értékhelyettesítéssel a PREPARE/EXECUTE-n keresztül
az ütemező munkájának emulálásához, amikor a parametrikus rész figyelmen kívül hagyható - például particionált táblákon végzett munka során
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Tervek archívuma

Ragaszd be, elemezd, oszd meg a kollégákkal! A tervek archiválva maradnak, és később visszatérhet hozzájuk: magyarázat.tensor.ru/archive

De ha nem szeretné, hogy mások lássák tervét, ne felejtse el bejelölni a „Ne tegye közzé az archívumban” négyzetet.

A következő cikkekben a terv elemzése során felmerülő nehézségekről és döntésekről lesz szó.

Forrás: will.com

Amiről az EXPLAIN hallgat, és hogyan lehet beszélni