🥇Mistä EXPLAIN on hiljaa ja kuinka saada hänet puhumaan

Klassinen kysymys, jonka kehittäjä tuo DBA:lle tai yrityksen omistaja PostgreSQL-konsultille, kuulostaa melkein aina samalta: "Miksi pyyntöjen käsittely tietokannassa kestää niin kauan?"

Perinteiset syyt:

tehoton algoritmi
kun päätät LIITTYÄ useisiin CTE:ihin muutaman kymmenen tuhannen levyn yli
vanhentuneet tilastot
jos tietojen todellinen jakauma taulukossa on jo hyvin erilainen kuin ANALYZE viime kerralla keräämä
"liitä" resursseihin
eikä suorittimen laskentatehoa ole enää tarpeeksi, muistia pumpataan jatkuvasti gigatavua tai levy ei pysty vastaamaan tietokannan "toiveisiin"
estäminen kilpailevista prosesseista

Ja jos tukoksia on melko vaikea saada kiinni ja analysoida, niin kaikkeen muuhun tarvitsemme kyselysuunnitelma, jonka voi hankkia käyttämällä SELITYS operaattori (On tietysti parempi heti SELITYS (ANALYSOIDA, PUSKURIT) ...) tai auto_explain-moduuli.

Mutta kuten samassa asiakirjoissa todetaan,

"Suunnitelman ymmärtäminen on taidetta, ja sen hallitseminen vaatii jonkin verran kokemusta..."

Mutta voit tehdä ilman sitä, jos käytät oikeaa työkalua!

Miltä kyselysuunnitelma yleensä näyttää? Jotain sellaista:

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

tai näin:

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

Mutta suunnitelman lukeminen tekstissä "arkista" on erittäin vaikeaa ja epäselvää:

näkyy solmussa summa alipuuresurssien mukaan
eli ymmärtääksesi kuinka kauan tietyn solmun suorittamiseen kului aikaa tai kuinka paljon tämä taulukon lukema toi tietoja levyltä, sinun on jotenkin vähennettävä yksi toisesta
solmuaikaa tarvitaan kerrotaan silmukoilla
kyllä, vähennys ei ole monimutkaisin operaatio, joka täytyy tehdä "päässä" - loppujen lopuksi suoritusaika on ilmoitettu keskimääräiseksi solmun yhdelle suoritukselle, ja niitä voi olla satoja
no, ja kaikki tämä yhdessä estää meitä vastaamasta pääkysymykseen - niin kuka "heikoin lenkki"?

Kun yritimme selittää kaiken tämän useille sadoille kehittäjillemme, ymmärsimme, että ulkopuolelta se näytti suunnilleen tältä:

Ja se tarkoittaa, että tarvitsemme...

Työkalu

Siihen yritimme kerätä kaikki keskeiset mekaniikat, jotka auttavat ymmärtämään "kuka on syyllinen ja mitä tehdä" suunnitelman ja pyynnön mukaisesti. No, ja jaa osa kokemuksistasi yhteisön kanssa.
Tutustu ja käytä - selittää.tensor.ru

Suunnitelmien näkyvyys

Onko suunnitelman ymmärtäminen helppoa, kun se näyttää tältä?

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

Ei oikeastaan.

Mutta näin, lyhennetyssä muodossaKun avainindikaattorit erotetaan toisistaan, se on paljon selkeämpi:

Mutta jos suunnitelma on monimutkaisempi, hän tulee apuun ympyräkaavion aikajakauma solmujen mukaan:

No, vaikeimmissa vaihtoehdoissa hänellä on kiire auttamaan edistymiskaavio:

On esimerkiksi melko ei-triviaaleja tilanteita, joissa suunnitelmalla voi olla useampi kuin yksi todellinen juuri:

Rakenteellisia vihjeitä

No, jos koko suunnitelman rakenne ja sen kipeät kohdat ovat jo valmiina ja näkyvissä, miksi et korostaisi niitä kehittäjälle ja selitä niitä "venäjän kielellä"?

Olemme keränneet jo pari tusinaa tällaisia suositusmalleja.

Rivi-rivi-kyselyprofiili

Jos nyt lisäät alkuperäisen kyselyn analysoidun suunnitelman päälle, voit nähdä, kuinka paljon aikaa käytettiin kuhunkin yksittäiseen lauseeseen - jotain tällaista:

...tai vaikka näin:

Parametrien korvaaminen pyynnöllä

Jos olet "liittänyt" suunnitelman lisäksi pyynnön, vaan myös sen parametrit lokin DETAIL-riviltä, voit lisäksi kopioida sen johonkin seuraavista vaihtoehdoista:

arvokorvauksella kyselyssä
suoraa suorittamista varten tukikohdassasi ja jatkoprofilointia varten
```
SELECT 'const', 'param'::text;
```
arvon korvauksella PREPARE/EXECUTE-toiminnolla
emuloida ajoittimen työtä, kun parametrinen osa voidaan jättää huomiotta - esimerkiksi työskennellessäsi osioiduilla taulukoilla
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Suunnitelmien arkisto

Liitä, analysoi, jaa työtovereiden kanssa! Suunnitelmat säilyvät arkistoituina ja voit palata niihin myöhemmin: selittää.tensor.ru/archive

Mutta jos et halua muiden näkevän suunnitelmaasi, älä unohda valita "älä julkaise arkistossa" -ruutua.

Seuraavissa artikkeleissa puhun vaikeuksista ja päätöksistä, joita syntyy suunnitelman analysoinnissa.

Lähde: will.com

Mikä EXPLAIN vaikenee ja kuinka saada se puhumaan