Indici și B-Trees

Cum poate o bază de date să găsească o singură înregistrare între milioane de rânduri în fracțiuni de secundă?

În mod implicit, când întrebăm SELECT * FROM customers WHERE city = 'Milano', Postgres trebuie să efectueze o Scanare secvențială: citește fizic întregul tabel de pe disc rând cu rând, comparând fiecare oraș cu „Milano”. Când o masă deține milioane de înregistrări, acest proces paralizează performanța.

Principalul răspuns structural la aceste blocaje sunt Indici.

Indici (arbori B)

Indecșii funcționează exact ca indexul analitic din spatele unei cărți mari. În loc să citim întreaga carte pentru a găsi unde se vorbește despre „Milano”, căutăm paginile din spate unde cuvântul „Milano” ne redirecționează către [p. 45, 114, 230]. Bazele de date, în culise, construiesc această structură de date separată, foarte compactă (adesea un „B-Tree”) ordonate după coloana sau coloanele în cauză, conținând pointeri directe către stocarea fizică a rândurilor potrivite.

-- Creare un indice semplice
CREATE INDEX idx_customers_city ON customers(city);

Această singură operație declanșează motorul Postgres, care va extrage și indexa toate valorile city în fundal. Odată finalizat, fiecare SELECT ... WHERE city = '...' ulterioară va zbura!

Chei primare și unicitate

Știați că cheia primară (PRIMARY KEY) și regulile cheii UNIQUE folosesc în secret indici sub capotă? Deoarece DB trebuie să se asigure că un e-mail sau un ID nu este niciodată duplicat la inserarea sau modificarea rândurilor, PostgreSQL creează automat un index B-Tree implicit deasupra acestora: astfel verificările de unicitate durează microsecunde.

De aceea, aderările în câmpul ID sunt incredibil de performante.

Aruncarea unui index

Dacă vă dați seama că interogările grele s-au schimbat și un index nu este niciodată consultat, este înțelept să îl distrugeți și să recuperați spațiu vital:

DROP INDEX idx_customers_city;

Rândul tău

Explorarea indicilor unici secundari