EXPLAIN rodo PostgreSQL užklausos vykdymo planą — kaip ji bus vykdyta (kokie scanai, joinai, indeksai). EXPLAIN ANALYZE iš tikrųjų vykdo užklausą ir parodo tikrą laiką bei eilučių skaičius. Tai yra pagrindiniai įrankiai lėtų užklausų diagnostikai.
EXPLAIN orders customer_id ;
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- ACTUALLY runs it → shows REAL time, ACTUAL rows, and where time was spent
EXPLAIN (ANALYZE, BUFFERS) SELECT ...; -- also shows buffer/cache usage
EXPLAIN ANALYZE yra naudingesnis, nes rodo tikrą veikimą (tikras laikus, tikrus eilučių skaičius) — atskleidžia, kur užklausa iš tikrųjų leidžia laiką, o ne tik sąmatas.
SCAN TYPES (most important):
Seq Scan → FULL TABLE SCAN (reads every row) — slow on big tables, often the problem
Index Scan → uses an index to find rows — fast
Index Only Scan → reads only the index (doesn't touch the table) — fastest
Bitmap Scan → for combining indexes / many matches
WATCH FOR:
✗ Seq Scan on a large table being filtered → likely a MISSING INDEX
✗ Estimated rows VERY different from actual rows → outdated statistics (run ANALYZE)
✗ Expensive joins, sorts spilling to disk ("external merge")
✗ The node with the highest actual time = the bottleneck
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → a full scan, slow
CREATE INDEX idx_orders_customer ON orders(customer_id);
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Index Scan using idx_orders_customer ... actual time=0.05ms" → fixed!
EXPLAIN ir EXPLAIN ANALYZE yra esminiai, pirminiai lėtų užklausų diagnostikos ir optimizavimo įrankiai PostgreSQL — užklausos veikimas yra kritinis programoms, ir šie įrankiai parodo, kodėl užklausa yra lėta ir patvirtina pataisas, todėl jų valdymas yra svarbus aukšto lygio žinios duomenų bazės veikimui.
Pagrindinė vertė yra matomumas vykdymo plane: užuot spėjus, kodėl užklausa yra lėta, EXPLAIN ANALYZE (kuris vykdo užklausą ir rodo tikrą laiką bei eilučių skaičius) tiksliai parodo, kaip Postgres ją vykdo ir kur leidžiamas laikas.
Svarbiausias dalykas, kurį reikia atpažinti, yra scan tipai — ypač identifikavimas Seq Scan (pilnos lentos skenavimu)** didelėje filtruotoje lentelėje, kuris paprastai rodo **trūkstamą indeksą** (dažniausias ir poveikiausias užklausos veikimo problema), o ne greitą **Index Scan`.
Supratimas, kaip skaityti planą (scan tipai, apskaičiuotų vs tikrų eilučių palyginimas, kad būtų nustatyta pasenusi statistika, brangiausiojo mazgo identifikavimas kaip pyrago viršus, žiūrėjimas į disko-išsipilstančius sortavimus) yra pagrindinė užklausos optimizavimo įgūdis.
Diagnostinis darbo srautas — paleisti EXPLAIN ANALYZE, nustatyti pyrago viršų (dažnai Seq Scan), taikyti pataisą (paprastai pridedant indeksą) ir iš naujo paleisti, norint patvirtinti — yra standartinis, matavimo pagrindu grįstas užklausos optimizavimo metodas.
NuolatDėl to, kad lėtos užklausos yra svarbiausias blogos duomenų bazės veikimo veiksnys, ir dėl to, kad EXPLAIN/EXPLAIN ANALYZE yra tie įrankiai joms diagnostikuoti (atskleidžiant trūkstamus indeksus, blogus planus ir pyrago viršus) ir optimizavimams patvirtinti, jų valdymas yra svarbi, aukštos vertės žinios PostgreSQL veikimui — tai yra tai, kaip sistemingai surasti ir pataisyti lėtas užklausas, o ne spėti, pagrindinį įgūdį veiklingoms duomenų bazėms ir dažną duomenų bazės optimizavimo darbo temą.