„Ar trebui să uităm de micile eficiențe, să zicem cam 97% din timp: optimizarea prematură e rădăcina tuturor relelor. Și totuși n-ar trebui să ratăm ocaziile din acele critice 3%.”Donald Knuth · Structured Programming with go to Statements · 1974 · Structured Programming with go to Statements, ACM Computing Surveys 6(4), 1974
Citește planul înainte să optimizezi: cele 3% critice au un nume, și de obicei e un join.
Trei algoritmi. Nested loop: pentru fiecare rând dintr-o parte, caută în cealaltă — imbatabil când o parte e minusculă sau cealaltă e indexată pe cheie, dezastruos între două tabele mari. Hash join: construiește o tabelă hash din partea mai mică, apoi trece o singură dată prin partea mare și potrivește — calul de povară al depozitului, cu condiția ca partea mică să încapă în memorie; dacă nu, se varsă pe disc și devine de zece ori mai lent. Merge join: ambele părți sortate pe cheie, o singură trecere paralelă — perfect când datele sunt deja ordonate. Planificatorul alege dintre ele pe baza statisticilor; statistici vechi înseamnă plan greșit, deci actualizarea lor e întreținere, nu opțiune. În sistemele distribuite se adaugă o întrebare: unde se întâlnesc rândurile? O dimensiune mică se difuzează (broadcast) pe toate nodurile; două tabele mari se redistribuie (shuffle) după cheie, iar o cheie fierbinte — adesea NULL — trimite jumătate din date pe un singur nod. Și capcana clasică: join-ul pe o cheie neunică multiplică rândurile, tăcut; dimensiunea de tip 2 din lecția 11 e exemplul tipic. Înainte de a optimiza, citește planul. Cele 3% sunt acolo, cu nume.
De ce contează Nouă interogări din zece nu contează; a zecea ține tot raportul de dimineață, și în ea e un join care se varsă pe disc sau multiplică rânduri.