EXPLICAȚI și ANALIZAȚI

Te-ai întrebat vreodată cum alege baza de date dacă să folosească acel index frumos pe care tocmai l-ai creat? De îndată ce apăsați Enter într-o interogare (să zicem, o alăturare lungă cu un grup înlănțuit de), Planificatorul de interogări calculează zeci de strategii din mers pentru a efectua interogarea și o alege pe cea considerată, în teorie, a fi cea mai rapidă.

Dar, ca dezvoltator, trebuie să puteți privi în interiorul minții întunecate a Planificatorului de interogări.

EXPLICA

Pentru a descoperi cum intenționează să procedeze Planificatorul, trebuie doar să puneți cuvântul magic EXPLAIN la începutul interogării.

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

Rezultatul nu vor fi comenzile! În schimb, veți vedea planul în ieșire (cu statistici estimate):

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

Aceasta ne spune:

1. Planificatorul va folosi o Seq Scan (citire brută, secvenţială a întregului disc). Rău dacă există miliarde de comenzi.
2. Se estimează că vor fi returnate ~15 rânduri și calculează „costul” în ciclurile CPU preîncărcate.

EXPLICA ANALIZA

În timp ce EXPLAIN se bazează pe presupuneri algoritmice (pe baza statisticilor globale calculate în ultimele ore pe baza datelor), EXPLAIN ANALYZE de fapt rulează interogarea real (și așteaptă rezultatele logice complete), comparând timpul real scurs în termeni matematici absoluti.

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

Ura! Aici aflați că baza de date a decis să aplice o Scanare index pe indexul nostru secundar idx_orders_cust, luând un timp de execuție microscopic de o miime de secundă, sărind peste milioane de rânduri.

Rândul tău

Obținerea de valori veridice