🥇Çi EXPLAIN li ser bêdeng e û meriv çawa wî bipeyive

Pirsa klasîk a ku pêşdebirek ji DBA-ya xwe re an xwedan karsaziyek ji şêwirmendek PostgreSQL re tîne hema hema her gav yek deng e: "Çima daxwaznameyên li ser databasê ew qas dirêj digirin?"

Komek sedemên kevneşopî:

algorîtmaya bêbandor
gava ku hûn biryar didin ku hûn li ser çend deh hezaran tomar tev li çend CTE-yan bibin
statîstîkên negirêdayî
heke belavkirina rastîn a daneyan di tabloyê de jixwe ji ya ku cara paşîn ji hêla ANALYZE ve hatî berhev kirin pir cûda be
li ser çavkaniyan "pêç bikin".
û êdî têra xwe hêza hesabkirinê ya CPU-yê tune ye, gigabytes bîranîn bi domdarî têne pomp kirin, an jî dîsk nikare hemî "daxwazên" databasê bişopîne.
astengkirin ji pêvajoyên hevrikî

Û heke girtin û analîzkirina astengiyan pir dijwar e, wê hingê ji bo her tiştê din em hewce ne plana lêpirsînê, ku dikare bi kar bîne operator BİXWÎNE (Bê guman, çêtir e ku meriv tavilê RÊVEKIRIN (ANALÎZ, BUFFER) ...) an module auto_explain.

Lê, wekî ku di heman belgeyê de tê gotin,

"Fêmkirina plansaziyek hunerek e, û ji bo serweriya wê çend ezmûnek hewce dike ..."

Lê heke hûn amûra rast bikar bînin hûn dikarin bêyî wê bikin!

Planek pirsê bi gelemperî çawa xuya dike? Tiştekî wisa:

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

an jî wek vê:

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

Lê xwendina plana di nivîsê de "ji pelê" pir dijwar û ne diyar e:

di nodê de tê nîşandan ji hêla çavkaniyên binê darê ve tê berhev kirin
ango, ji bo ku hûn fêm bikin ka ji bo cîbicîkirina girêkek taybetî çiqas dem girt, an jî bi rastî ev xwendina ji tabloyê çiqas daneyên ji dîskê derxistiye, hûn hewce ne ku bi rengekî yek ji ya din derxînin.
dema node pêwîst e bi lûkan zêde dikin
erê, jêbirin ne operasyona herî tevlihev e ku divê "di serî" de were kirin - her wusa, dema darvekirinê wekî navînî ji bo yek darvekirina girêkek tê destnîşan kirin, û dibe ku bi sedan ji wan hebin.
baş e, û ev hemî bi hev re nahêle ku em bersiva pirsa sereke bidin - îcar kî "girêka herî qels"?

Dema ku me hewl da ku em van hemî ji çend sed ji pêşdebirên xwe re rave bikin, me fêm kir ku ji derve ve tiştek weha xuya dike:

Û ev tê vê wateyê ku em hewce ne ...

Instrument

Di wê de me hewl da ku li gorî plan û daxwazê hemû mekanîzmayên sereke yên ku alîkariya têgihîştina "kê sûcdar e û çi bike" berhev bikin. Welê, û beşek ji ezmûna xwe bi civakê re parve bikin.
Hevdîtin û bikar bînin - şirove.tensor.ru

Dîtina planan

Dema ku ew bi vî rengî xuya dike fêmkirina planê hêsan e?

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

Bi rastî na.

Lê bi vî rengî, bi forma kurtkirîgava ku nîşanên sereke têne veqetandin, ew pir zelaltir e:

Lê heke plan tevlihevtir be, ew ê bigihîje alîkariyê belavkirina dema piechart ji hêla girêkan:

Welê, ji bo vebijarkên herî dijwar ew ji bo alîkariyê bilezîne nexşeya pêşveçûnê:

Mînakî, rewşên bêkêmasî hene ku dibe ku planek ji yek rootek rastîn hebe:

Nîşaneyên strukturel

Welê, heke tevahiya avahiya planê û lekeyên wê yên êş ji berê ve hatine danîn û xuyang kirin, çima wan ji pêşdebiran re ronî nakin û wan bi "zimanê rûsî" rave nakin?

Me berê jî du deh şablonên pêşniyarên weha berhev kirine.

Rêz-bi-xêz profîlkerê pirsê

Naha, heke hûn pirsa orîjînal li ser plansaziya analîzkirî bicîh bikin, hûn dikarin bibînin ka çiqas dem li ser her daxuyaniyek kesane derbas bûye - tiştek weha:

an jî bi vî rengî:

Veguheztina parametreyan di daxwazekê de

Ger we ne tenê daxwazek bi planê ve, lê di heman demê de pîvanên wê jî ji rêza DETAIL ya têketinê "ve girêdide", hûn dikarin wê di yek ji vebijarkan de jî kopî bikin:

bi cîgirkirina nirxê di pirsê de
ji bo darvekirina rasterast li ser bingeha we û profîla bêtir
```
SELECT 'const', 'param'::text;
```
bi cîgirkirina nirxê bi rêya AMADEKIRINA / EXECUTE
ji bo nimûnekirina xebata plansazker, gava ku beşa parametrîkî dikare were paşguh kirin - mînakî, dema ku li ser tabloyên dabeşkirî dixebitin
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Arşîva planan

Paste, analîz bikin, bi hevkaran re parve bikin! Plan dê arşîvkirî bimînin û hûn dikarin paşê vegerin wan: şirove bike.tensor.ru/archive

Lê heke hûn nexwazin yên din plana we bibînin, ji bîr nekin ku qutiya "di arşîvê de neweşînin" kontrol bikin.

Di gotarên jêrîn de ez ê li ser dijwarî û biryarên ku di dema analîzkirina plansaziyê de derdikevin biaxivim.

Source: www.habr.com

Tiştê ku EXPLAIN li ser bêdeng e û meriv wê çawa biaxive