Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Pitakonan klasik sing digawa pangembang menyang DBA utawa pemilik bisnis menyang konsultan PostgreSQL meh padha: "Napa panjaluk mbutuhake wektu suwe kanggo ngrampungake ing database?"

Alasan tradisional:

  • algoritma ora efisien
    nalika sampeyan mutusake kanggo gabung karo sawetara CTE liwat sawetara puluhan ewu rekaman
  • statistik sing ora cocog
    yen distribusi nyata data ing tabel wis beda banget saka sing diklumpukake dening ANALYZE pungkasan
  • "plug" ing sumber daya
    lan ora ana daya komputasi khusus CPU maneh, memori gigabyte terus dipompa, utawa disk ora bisa ngetutake kabeh "kepengin" database.
  • pamblokiran saka proses saingan

Lan yen pamblokiran cukup angel kanggo nyekel lan nganalisa, mula kabeh sing dibutuhake rencana pitakon, sing bisa dipikolehi nggunakake Njelasake operator (Iku luwih apik, mesthi, kanggo langsung nerangake (ANALYZE, BUFFERS) ...) utawa auto_explain modul.

Nanging, kaya sing kasebut ing dokumentasi sing padha,

"Mangertos rencana minangka seni, lan kanggo nguwasani iku mbutuhake pengalaman tartamtu ..."

Nanging sampeyan bisa nindakake tanpa yen sampeyan nggunakake alat sing bener!

Apa rencana pitakon biasane katon kaya? Kaya ngono:

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

utawa kaya iki:

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

Nanging maca rencana ing teks "saka lembaran" angel banget lan ora jelas:

  • ditampilake ing simpul jumlah dening sumber daya subtree
    iku, kanggo ngerti carane akeh wektu iku njupuk kanggo nglakokaké simpul tartamtu, utawa carane persis maca iki saka meja nggawa data saka disk, sampeyan kudu piye wae nyuda siji saka liyane.
  • wektu node dibutuhake multiply dening puteran
    Ya, subtraction dudu operasi sing paling rumit sing kudu ditindakake "ing sirah" - sawise kabeh, wektu eksekusi dituduhake minangka rata-rata kanggo siji eksekusi simpul, lan bisa uga ana atusan.
  • uga, lan kabeh iki bebarengan nyegah kita njawab pitakonan utama - supaya sing "link paling lemah"?

Nalika kita nyoba nerangake kabeh iki menyang sawetara atus pangembang, kita ngerti yen saka njaba katon kaya iki:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Lan tegese kita kudu ...

Instrumen

Ing kono kita nyoba ngumpulake kabeh mekanika kunci sing mbantu ngerti "sapa sing kudu disalahake lan apa sing kudu ditindakake" miturut rencana lan panjaluk. Inggih, lan nuduhake bagéan saka pengalaman karo masyarakat.
Ketemu lan nggunakake - nerangake.tensor.ru

Visibilitas rencana

Apa gampang mangertos rencana nalika katon kaya iki?

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

Ora tenanan.

Nanging kaya iki, ing wangun singkatannalika indikator utama dipisahake, luwih jelas:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Nanging yen rencana luwih rumit, dheweke bakal nulungi distribusi wektu piechart dening node:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Ya, kanggo pilihan sing paling angel, dheweke cepet-cepet nulungi grafik kemajuan:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Contone, ana kahanan sing ora pati penting nalika rencana bisa duwe luwih saka siji root nyata:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomongApa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Petunjuk struktural

Ya, yen kabeh struktur rencana lan bintik-bintik lara wis ditata lan katon, kenapa ora nyorot menyang pangembang lan nerangake ing "basa Rusia"?

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomongKita wis nglumpukake sawetara rolas template rekomendasi kasebut.

Line-by-line query profiler

Saiki, yen sampeyan nglebokake pitakon asli menyang rencana sing dianalisis, sampeyan bisa ndeleng sepira suwene wektu kanggo saben statement - kaya iki:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

... utawa malah kaya iki:

Apa EXPLAIN bisu babagan lan carane njaluk iku ngomong

Ngganti paramèter menyang panyuwunan

Yen sampeyan "dilampirake" ora mung panjalukan kanggo rencana, nanging uga paramèter saka baris DETAIL log, sampeyan bisa uga nyalin ing salah siji opsi:

  • karo substitusi nilai ing query
    kanggo eksekusi langsung ing basis lan profil luwih lanjut

    SELECT 'const', 'param'::text;
  • kanthi substitusi nilai liwat PREPARE / EXECUTE
    kanggo niru karya panjadwal, nalika bagean parametrik bisa diabaikan - contone, nalika nggarap tabel partisi

    DEALLOCATE ALL;
    PREPARE q(text) AS SELECT 'const', $1::text;
    EXECUTE q('param'::text);
    

Arsip saka rencana

Tempel, analisa, bareng karo kolega! Rencana kasebut bakal tetep diarsipake lan sampeyan bisa bali maneh mengko: explain.tensor.ru/archive

Nanging yen sampeyan ora pengin wong liya ndeleng rencana sampeyan, aja lali mriksa kothak "aja nerbitake ing arsip".

Ing artikel ing ngisor iki aku bakal ngomong babagan kesulitan lan keputusan sing muncul nalika nganalisa rencana.

Source: www.habr.com

Add a comment