🥇 Am beth mae EXPLAIN yn dawel a sut i'w gael i siarad

Mae'r cwestiwn clasurol y mae datblygwr yn ei roi i'w DBA neu berchennog busnes yn dod ag ymgynghorydd PostgreSQL bron bob amser yn swnio'r un peth: “Pam mae ceisiadau’n cymryd cymaint o amser i’w cwblhau ar y gronfa ddata?”

Set draddodiadol o resymau:

algorithm aneffeithlon
pan fyddwch chi'n penderfynu YMUNO â sawl CTE dros ychydig o ddegau o filoedd o gofnodion
ystadegau hen ffasiwn
os yw dosbarthiad gwirioneddol y data yn y tabl eisoes yn wahanol iawn i'r un a gasglwyd gan ANALYZE y tro diwethaf
"plwg" ar adnoddau
ac nid oes digon o bŵer cyfrifiadurol pwrpasol gan y CPU bellach, mae gigabeit o gof yn cael ei bwmpio'n gyson, neu ni all y ddisg gadw i fyny â holl “eisiau” y gronfa ddata
blocio o brosesau cystadleuol

Ac os yw blociau'n eithaf anodd eu dal a'u dadansoddi, yna ar gyfer popeth arall sydd ei angen arnom cynllun ymholiad, y gellir ei gael gan ddefnyddio ESBONIO gweithredwr (Mae'n well, wrth gwrs, ESBONIO (DADANSODDIAD, BUFFERS) ar unwaith ...) neu modiwl auto_explain.

Ond, fel y nodir yn yr un ddogfennaeth,

“Mae deall cynllun yn gelfyddyd, ac mae angen rhywfaint o brofiad i’w feistroli...”

Ond gallwch chi wneud hebddo os ydych chi'n defnyddio'r offeryn cywir!

Sut olwg sydd ar gynllun ymholiad fel arfer? Rhywbeth fel hynny:

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

neu fel hyn:

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

Ond mae darllen y cynllun mewn testun “o’r ddalen” yn anodd iawn ac yn aneglur:

yn cael ei arddangos yn y nod swm gan adnoddau subtree
hynny yw, er mwyn deall faint o amser a gymerodd i weithredu nod penodol, neu faint yn union y mae'r darlleniad hwn o'r tabl wedi dod â data i fyny o'r ddisg, mae angen i chi rywsut dynnu un o'r llall
mae angen amser nod lluoswch â dolenni
ie, nid tynnu yw'r gweithrediad mwyaf cymhleth y mae angen ei wneud "yn y pen" - wedi'r cyfan, nodir yr amser cyflawni fel y cyfartaledd ar gyfer un gweithrediad nod, a gall fod cannoedd ohonynt
wel, ac mae hyn i gyd gyda'n gilydd yn ein rhwystro rhag ateb y prif gwestiwn - felly pwy "y ddolen wannaf"?

Pan geisiwyd egluro hyn i gyd i gannoedd o'n datblygwyr, sylweddolom ei fod yn edrych fel hyn o'r tu allan:

Ac mae hynny'n golygu bod angen i ni...

Offeryn

Ynddo fe wnaethon ni geisio casglu’r holl fecanegau allweddol sy’n helpu i ddeall “pwy sydd ar fai a beth i’w wneud” yn ôl y cynllun a’r cais. Wel, a rhannwch ran o'ch profiad gyda'r gymuned.
Cyfarfod a defnyddio - esbonio.tensor.ru

Gwelededd cynlluniau

Ydy hi'n hawdd deall y cynllun pan mae'n edrych fel hyn?

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

Ddim mewn gwirionedd.

Ond fel hyn, mewn ffurf grynopan gaiff y dangosyddion allweddol eu gwahanu, mae’n llawer cliriach:

Ond os yw'r cynllun yn fwy cymhleth, fe ddaw i'r adwy dosbarthu amser siart cylch gan nodau:

Wel, ar gyfer yr opsiynau anoddaf mae ar frys i helpu siart cynnydd:

Er enghraifft, mae sefyllfaoedd eithaf dibwys pan fydd gan gynllun fwy nag un gwraidd gwirioneddol:

Cliwiau strwythurol

Wel, os yw strwythur cyfan y cynllun a'i smotiau dolurus eisoes wedi'u gosod allan ac yn weladwy, beth am eu hamlygu i'r datblygwr a'u hegluro yn “iaith Rwsieg”?

Rydym eisoes wedi casglu cwpl o ddwsin o dempledi argymhellion o'r fath.

Amlinellydd ymholiad llinell wrth linell

Nawr, os ydych yn arosod yr ymholiad gwreiddiol ar y cynllun a ddadansoddwyd, gallwch weld faint o amser a dreuliwyd ar bob datganiad unigol - rhywbeth fel hyn:

...neu hyd yn oed fel hyn:

Amnewid paramedrau i gais

Os gwnaethoch chi “atodi” nid yn unig gais i'r cynllun, ond hefyd ei baramedrau o linell MANYLION y log, gallwch chi hefyd ei gopïo yn un o'r opsiynau:

gydag amnewidiad gwerth yn y cais
ar gyfer gweithredu uniongyrchol ar eich sylfaen a phroffilio pellach
```
SELECT 'const', 'param'::text;
```
gydag amnewidiad gwerth trwy PREPARE / EXECUTE
i efelychu gwaith yr amserlennydd, pan ellir anwybyddu'r rhan barametrig - er enghraifft, wrth weithio ar dablau rhanedig
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Archif o gynlluniau

Gludo, dadansoddi, rhannu gyda chydweithwyr! Bydd y cynlluniau yn parhau i gael eu harchifo a gallwch ddychwelyd atynt yn ddiweddarach: esbonio.tensor.ru/archive

Ond os nad ydych chi am i eraill weld eich cynllun, peidiwch ag anghofio ticio'r blwch “peidiwch â chyhoeddi yn yr archif”.

Yn yr erthyglau canlynol byddaf yn sôn am yr anawsterau a'r penderfyniadau sy'n codi wrth ddadansoddi cynllun.

Ffynhonnell: hab.com

Am beth mae ESBONIAD yn dawel a sut i'w gael i siarad