🥇 Naon EXPLAIN anu cicingeun sareng kumaha carana ngajantenkeun anjeunna ngobrol

Patarosan klasik anu dibawa ku pamekar ka DBA atanapi pamilik usaha anu dibawa ka konsultan PostgreSQL ampir sok disada sami: "Naha requests nyandak jadi lila pikeun ngalengkepan dina database?"

Alesan tradisional:

algoritma teu episien
nalika anjeun mutuskeun pikeun ngagabung sababaraha CTE dina sababaraha puluhan rébu rékaman
statistik luntur
lamun sebaran sabenerna data dina tabél geus pisan béda ti hiji dikumpulkeun ku ANALYZE panungtungan waktu
"nyolok" dina sumberdaya
sareng kakuatan komputasi khusus CPU henteu cekap deui, mémori gigabyte terus-terusan dipompa, atanapi disk henteu tiasa ngiringan sadaya "hayang" pangkalan data.
ngahalangan tina prosés bersaing

Tur upami blockings rada hese nyekel jeung analisa, teras pikeun sagalana sejenna urang peryogi rencana query, nu bisa didapet maké NERANGKEUN operator (Éta langkung saé, tangtosna, langsung NERANGKEUN (ANALYZE, BUFFERS) ...) atanapi auto_explain modul.

Tapi, sakumaha nyatakeun dina dokuméntasi anu sami,

"Ngartos rencana mangrupikeun seni, sareng ngawasaan éta peryogi sababaraha pangalaman ..."

Tapi anjeun tiasa ngalakukeun tanpa éta upami anjeun nganggo alat anu leres!

Kumaha rencana query biasana katingalina? Sapertos kitu:

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

atanapi sapertos kieu:

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

Tapi maca rencana dina téks "tina lambaran" hésé pisan jeung teu jelas:

dipintonkeun dina node jumlah ku sumberdaya subtree
nyaeta, ngartos sabaraha lila waktu nu diperlukeun pikeun ngaéksekusi titik tinangtu, atawa sabaraha persis bacaan ieu tina tabel dibawa nepi data ti disk, Anjeun kudu kumaha bae subtract hiji ti lianna.
waktos node diperlukeun kalikeun ku loop
Leres, pangurangan sanés mangrupikeun operasi anu paling rumit anu kedah dilakukeun "dina sirah" - saatosna, waktos palaksanaan dituduhkeun rata-rata pikeun hiji palaksanaan titik, sareng tiasa aya ratusan diantarana.
sumur, sarta sakabeh ieu babarengan nyegah urang ngajawab patarosan utama - jadi saha "link paling lemah"?

Nalika kami nyobian ngajelaskeun sadayana ieu ka sababaraha ratus pamekar kami, kami sadar yén ti luar éta katingali sapertos kieu:

Sareng éta hartosna urang peryogi ...

Instrumén

Di jerona urang diusahakeun ngumpulkeun sakabeh mékanika konci nu mantuan ngartos "saha anu kudu ngalepatkeun na naon nu kudu" nurutkeun rencana na pamundut. Nya, sareng bagikeun bagian tina pangalaman anjeun sareng komunitas.
Papanggih sareng dianggo - explain.tensor.ru

Visibilitas rencana

Éta gampang ngartos rencana lamun kasampak kawas kieu?

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

Teu bener.

Tapi sapertos kieu, dina wangun singgetanNalika indikator konci dipisahkeun, langkung jelas:

Tapi upami rencanana langkung rumit, anjeunna bakal nyalametkeun distribusi waktos piechart ku titik:

Nya, pikeun pilihan anu paling hese anjeunna buru-buru ngabantosan bagan kamajuan:

Contona, aya kaayaan rada non-trivial nalika rencana bisa mibanda leuwih ti hiji akar sabenerna:

Pitunjuk struktural

Nya, upami sadayana struktur rencana sareng bintik nyeri na parantos ditata sareng katingali, naha henteu nyorot aranjeunna ka pamekar sareng ngajelaskeun dina "basa Rusia"?

Kami parantos ngumpulkeun sababaraha belasan témplat rekomendasi sapertos kitu.

Baris-demi-garis query profiler

Ayeuna, upami anjeun nempatkeun pamundut asli kana rencana anu dianalisis, anjeun tiasa ningali sabaraha waktos diséépkeun pikeun tiap pernyataan individu - sapertos kieu:

... atanapi malah sapertos kieu:

Ngagantikeun parameter kana pamundut

Upami anjeun "napel" henteu ngan ukur pamundut kana rencana, tapi ogé parameterna tina garis DETAIL log, anjeun ogé tiasa nyalin dina salah sahiji pilihan:

kalawan substitusi nilai dina query
pikeun palaksanaan langsung dina dasar anjeun sarta profil salajengna
```
SELECT 'const', 'param'::text;
```
kalawan substitusi nilai via Nyiapkeun / ngaéksekusi
pikeun niru karya scheduler, nalika bagian parametrik tiasa dipaliré - contona, nalika dianggo dina tabel partitioned
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Arsip rencana

Témpél, analisa, bagikeun sareng kolega! Rencanana bakal tetep diarsipkeun sareng anjeun tiasa uih deui engké: explain.tensor.ru/archive

Tapi upami anjeun henteu hoyong batur ningali rencana anjeun, tong hilap pariksa kotak "ulah nyebarkeun dina arsip".

Dina tulisan di handap ieu kuring bakal ngobrol ngeunaan kasusah sareng kaputusan anu timbul nalika nganalisa rencana.

sumber: www.habr.com

Naon EXPLAIN nyaéta jempé ngeunaan sareng kumaha carana nyarios