EXPLAIN i ANALYZE

Czy zastanawiałeś się kiedyś, w jaki sposób baza danych decyduje, czy użyć tego ładnego indeksu, który właśnie utworzyłeś? Gdy tylko naciśniesz Enter w zapytaniu (powiedzmy, długim łączeniu z grupą powiązaną według), Planer zapytań na bieżąco oblicza dziesiątki strategii w celu wykonania zapytania i wybiera tę, która teoretycznie jest najszybsza.

Ale jako programista musisz móc zajrzeć do mrocznego umysłu Planisty zapytań.

WYJAŚNIĆ

Aby dowiedzieć się, jak Planner zamierza postępować, po prostu umieść magiczne słowo EXPLAIN na początku zapytania.

EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

Rezultatem nie będą zamówienia! Zamiast tego zobaczysz plan w wynikach (z szacunkowymi statystykami):

Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

To nam mówi:

1. Planista użyje Seq Scan (brute, sekwencyjny odczyt całego dysku). Źle, jeśli są miliardy zamówień.
2. Szacuje, że zostanie zwróconych około 15 wierszy i oblicza „koszt” w cyklach wstępnie załadowanego procesora.

WYJAŚNIJ ANALIZĘ

Podczas gdy EXPLAIN opiera się na domysłach algorytmicznych (w oparciu o globalne statystyki obliczone w ciągu ostatnich kilku godzin na danych), EXPLAIN ANALYZE faktycznie uruchamia zapytanie (i czeka na pełne wyniki logiczne), porównując rzeczywisty czas, który upłynął, w wartościach matematycznie bezwzględnych.

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;

Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

Brawo! Tutaj dowiesz się, że baza danych zdecydowała się zastosować Skanowanie indeksu na naszym dodatkowym indeksie idx_orders_cust, co zajmuje mikroskopijny czas wykonania wynoszący jedną tysięczną sekundy i pomija miliony wierszy w locie.

Twoja kolej

Uzyskiwanie prawdziwych danych