Spori upiti baze podataka rijetko se najave kao jedan dramatičan kvar. Češće se pojave kao stranica koja djeluje pomalo tromo, red čekanja koji stalno raste ili API krajnja točka koja postaje nepouzdana pri uobičajenom prometu. Dobra je vijest da optimizacija upita ne počinje egzotičnim trikovima. Počinje discipliniranom navikom: izmjerite stvarni upit, razumijte posao koji baza podataka obavlja i uklanjajte nepotreban rad sloj po sloj.

Za backend timove baza podataka obično je zajedničko usko grlo. Upit koji je samo neefikasan izolirano može postati skup kada se izvršava stotine puta tijekom ciklusa zahtjeva ili među mnogim istodobnim radnicima. Pragmatična optimizacija štiti i latenciju i operativnu rezervu kapaciteta.

Počnite s dokazima, a ne intuicijom

Najčešća pogreška pri optimizaciji jest optimizirati upit koji izgleda sumnjivo umjesto onoga koji troši značajno vrijeme. Dnevnici aplikacije, evidentiranje sporih upita, tragovi zahtjeva i nadzor baze podataka trebali bi pomoći utvrditi koje su naredbe spore, česte ili oboje.

Zabilježite potpuni oblik upita: SQL, vezane vrijednosti ili reprezentativne vrijednosti, vrijeme izvršavanja, broj vraćenih redaka i učestalost pozivanja. Upit koji traje 80 milisekundi jednom dnevno zaslužuje drukčiju pozornost od upita koji traje 8 milisekundi pedeset puta tijekom svakog API zahtjeva.

Zatim pregledajte plan izvršavanja. Većina relacijskih baza podataka pruža mogućnost EXPLAIN, a mnoge mogu prijaviti stvarne pojedinosti vremena izvođenja putem varijante za analizu. Točan se izlaz razlikuje ovisno o bazi podataka, ali pitanja ostaju dosljedna:

• Čita li baza podataka daleko više redaka nego što rezultat zahtijeva?
• Koristi li odgovarajući indeks ili skenira cijelu tablicu?
• Umnožavaju li spajanja redove neočekivano?
• Događa li se sortiranje ili grupiranje nad velikim međurezultatom?
• Razlikuje li se procijenjeni broj redaka znatno od stvarnog broja?

Plan izvršavanja nije semafor na kojem je svako skeniranje tablice neuspjeh. Skeniranje male tablice za pretraživanje može biti jeftinije od korištenja indeksa. Problem je plan čiji rad loše raste kako podaci rastu.

Neka indeksi služe stvarnim obrascima pristupa

Indeksi su obično prvi koristan alat, ali „dodajte indeks svakom filtriranom stupcu” nije strategija. Svaki indeks troši prostor za pohranu i čini umetanja, ažuriranja i brisanja skupljima jer ga baza podataka mora održavati. Dizajnirajte indekse oko upita koje aplikacija stvarno šalje.

Razmotrite krajnju točku koja prikazuje nedavne račune kupca:

SELECT id, status, total_cents, created_at
FROM invoices
WHERE customer_id = ?
  AND status = ?
ORDER BY created_at DESC
LIMIT 50;

Složeni indeks koji počinje s customer_id i status, a zatim slijedi created_at, može omogućiti bazi podataka da pronađe odgovarajući podskup u traženom redoslijedu. Redoslijed stupaca je važan. Trebao bi najprije odražavati uvjete jednakosti, a zatim zahtjev za rasponom, sortiranjem ili grupiranjem.

Nemojte pretpostaviti da složeni indeks automatski pomaže svakoj varijaciji upita. Upit koji filtrira samo po kasnijem stupcu možda neće učinkovito koristiti indeks. Provjerite plan nakon stvaranja indeksa i provjerite poboljšava li upit u obliku iz produkcije, a ne pojednostavljeni test.

Neka predikati budu prilagođeni indeksima

Indeks je manje koristan kada upit transformira indeksirani stupac prije usporedbe. Ovaj obrazac može prisiliti bazu podataka da procijeni izraz za mnoge retke:

WHERE DATE(created_at) = '2026-09-29'

Raspon zadržava stupac nepromijenjenim i učinkovitije izražava istu namjeru:

WHERE created_at >= '2026-09-29 00:00:00'
  AND created_at < '2026-09-30 00:00:00'

Isto načelo vrijedi za nepotrebne pretvorbe tipova, pretraživanja sa zamjenskim znakom na početku poput LIKE '%term' i izraze obavijene oko ključeva spajanja. Ponekad su te operacije potrebne, ali treba ih prepoznati kao svjesne kompromise, a ne slučajne zadane postavke.

Dohvaćajte manje podataka i obavljajte manje ponovljenog rada

SELECT * praktičan je tijekom ranog razvoja, ali često postane nevidljiv trošak. Široka tekstna polja, JSON dokumenti i binarni podaci povećavaju čitanja s diska, pritisak na memoriju, mrežni prijenos i PHP rad pri hidrataciji. Odaberite polja koja krajnja točka ili posao zaista trebaju.

Paginacija zaslužuje jednako pažljivo razmatranje. Paginacija s pomakom jednostavna je:

SELECT id, created_at, title
FROM posts
ORDER BY created_at DESC
LIMIT 25 OFFSET 10000;

Ali veliki pomaci mogu zahtijevati da baza podataka prođe pokraj mnogih redaka prije vraćanja jedne stranice. Za uređene tokove i skupnu obradu, paginacija po ključu često je stabilnija:

SELECT id, created_at, title
FROM posts
WHERE (created_at, id) < (?, ?)
ORDER BY created_at DESC, id DESC
LIMIT 25;

Pokazivač mora sadržavati dovoljno informacija o redoslijedu kako bi slijed bio deterministički. Ovdje id razrješava izjednačenja kada više objava dijeli vremensku oznaku. Podržavajući indeks trebao bi odgovarati tom obrascu filtriranja i sortiranja.

Uklonite obrazac upita N+1

Upiti N+1 posebno su česti u PHP aplikacijama koje koriste ORM-ove. Rukovatelj učitava zbirku narudžbi, a zatim lijeno učitava kupca ili stavke za svaku narudžbu. Kod izgleda uredno, ali popis od 100 narudžbi može postati 101 povratno putovanje do baze podataka.

Rješenje nije uvijek „jedno golemo spajanje”. Spajanje može duplicirati podatke roditelja za svaki red djeteta, stvarajući velik skup rezultata i nezgodnu rekonstrukciju na strani aplikacije. Odaberite oblik koji odgovara odgovoru:

• Koristite žurno učitavanje ili skupni upit WHERE IN kada su povezani zapisi potrebni za mnoge roditelje.
• Koristite spajanje kada vraća prirodno ravan rezultat i izbjegava dodatna povratna putovanja.
• Koristite agregat kada stranica treba broj ili sažetak, a ne svaki zapis djeteta.
• Učitavajte pojedinosti na zahtjev samo kada ih krajnja točka doista ne zahtijeva.

Instrumentirajte broj upita po zahtjevu u razvojnim i testnim okruženjima. Metrika latencije sama može prikriti ponašanje N+1 na zagrijanoj lokalnoj bazi podataka; broj upita čini strukturni problem vidljivim.

Poštujte transakcije, zaključavanja i putanje pisanja

Optimizacija čitanja dobiva pozornost jer ju je lako promatrati, ali konkurencija pri pisanju može biti pravi izvor problema u produkciji. Neka transakcije budu kratke. Obavite validaciju, udaljene API pozive, obradu datoteka i skupe izračune prije otvaranja transakcije ili nakon njezina potvrđivanja kad god to ispravnost dopušta.

Unutar transakcije ažurirajte retke dosljednim redoslijedom kada više zapisa može biti zaključano. To smanjuje vjerojatnost da istodobne operacije čekaju jedna drugu u sukobljenim slijedovima. Rukujte zastojima kao uobičajenim prolaznim neuspjehom: ponovite cijelu transakciju samo kada je operaciju sigurno ponoviti, uz ograničen broj pokušaja i jasno izvještavanje o pogreškama.

U PHP-u opseg transakcije treba biti izričit i uzak. Pouzdan obrazac jest potvrditi pri uspjehu, poništiti pri neuspjehu i izbjeći gutanje iznimki zbog kojih pozivatelj vjeruje da je zapisivanje uspjelo.

Pažljivo predmemorirajte, zatim ponovno provjerite upit

Predmemoriranje je vrijedno za skupe, često tražene i sigurno ponovno upotrebljive rezultate. Nije zamjena za razumijevanje neispravnog upita. Ključevi predmemorije moraju uključivati svaki ulaz koji mijenja odgovor, a pravila invalidacije moraju odražavati zahtjeve za svježinom podataka.

Prije dodavanja predmemorije zapitajte se rješavaju li bolji indeks, manji rezultat, skupni obrazac pristupa ili unaprijed izračunat sažetak problem s manje složenosti. Kada je predmemoriranje prikladno, zaštitite bazu podataka od stampeda predmemorije koordiniranjem ponovnih izgradnji ili dopuštanjem kontroliranog čitanja zastarjelih podataka gdje ih proizvod može tolerirati.

Neka optimizacija postane ponovljiva inženjerska praksa

Trajna pouka nije popis SQL čarolija. To je petlja: promatrajte stvarno radno opterećenje, oblikujte konkretnu hipotezu, pregledajte plan, napravite jednu promjenu, ponovno izmjerite i zadržite promjenu samo ako poboljšava relevantan ishod bez štete za pisanja ili ispravnost.

Performanse baze podataka nagrađuju suzdržanost. Uzak indeks, precizan upit, razumna strategija učitavanja i kratka transakcija često nadmašuju opsežno prepisivanje. Svaki upit tretirajte kao dio većeg sustava rasta podataka, konkurentnosti, aplikacijskog koda i operativnih ograničenja, pa optimizacija postaje manje tajanstvena — i daleko pouzdanija.