Spori PHP zahtjev često se pripisuje „bazi podataka” mnogo prije nego što je itko saznao što baza podataka zapravo radi. Profileri su vrijedni: pokazuju gdje se vrijeme nakuplja, koja je krajnja točka pogođena i zaslužuje li upit pažnju. No profiler je početak istrage, a ne dijagnoza.

Korisno pitanje nije jednostavno: „Koji je upit spor?” Ono glasi: „Zašto je ovom upitu potrebno ovoliko rada da vrati ovaj rezultat?” Ta promjena pretvara rad na performansama iz niza nagađanja u ponovljivu inženjersku praksu.

Profiliranje pronalazi mjesto događaja; planovi upita objašnjavaju zločin

Trag zahtjeva može pokazati da je SQL naredba potrošila 800 milisekundi. To je korisno za djelovanje, ali nepotpuno. Kašnjenje može nastati zbog skeniranja previše redaka, sortiranja velikog međurezultata, spajanja tablica nepovoljnim redoslijedom, čekanja na zaključavanje, prijenosa prekomjerne količine podataka ili izvršavanja istog upita stotine puta.

Započnite bilježenjem točnog SQL-a, njegovih vezanih vrijednosti, proteklog vremena i konteksta zahtjeva. Vrijednosti parametara važne su jer upit koji je brz za selektivnu vrijednost može biti spor za čestu vrijednost. Izvješće filtrirano za jednog korisnika nije isto opterećenje kao izvješće filtrirano za većinu korisnika.

Za sustave kompatibilne s MySQL-om, pregledajte reprezentativnu naredbu pomoću EXPLAIN:

EXPLAIN
SELECT o.id, o.created_at, o.total
FROM orders AS o
WHERE o.account_id = 42
  AND o.created_at >= '2026-01-01'
ORDER BY o.created_at DESC
LIMIT 50;

Izlaz je plan, a ne presuda. Čitajte ga u kontekstu. Tražite obrasce pristupa koji upućuju na potpuno skeniranje kada ste očekivali ciljani dohvat, visoku procjenu pregledanih redaka ili dodatne operacije poput sortiranja i rukovanja privremenim rezultatima. Plan vam govori kako optimizator namjerava dohvatiti retke; ne govori vam je li aplikacija uopće zatražila prave retke.

Zapitajte se koji posao baza podataka mora obaviti

Indeksi se često smatraju univerzalnim lijekom. Nisu. Indeks pomaže kada odgovara načinu na koji se podaci filtriraju, spajaju ili sortiraju. Također povećava potrošnju prostora i opterećenje pri pisanju, pa dodavanje indeksa bez razumijevanja obrasca pristupa može premjestiti problem drugdje.

Razmotrite uobičajenu krajnju točku: nedavne narudžbe za račun, poredane prema vremenu stvaranja. Indeks oblikovan oko account_id i created_at može zajedno podržati filtriranje i sortiranje. Indeks samo na created_at i dalje može ostaviti bazi podataka da pregledava mnoge retke koji pripadaju drugim računima.

Točan redoslijed indeksa ovisi o upitu i mehanizmu baze podataka, ali načelo je stabilno: dizajnirajte indekse prema stvarnim predikatima i zahtjevima sortiranja, a zatim provjerite dobiveni plan. Nemojte zaključivati o uspjehu samo iz činjenice da indeks postoji.

Također pazite na izraze koji inače korisne indekse čine težima za korištenje. Filtriranje funkcijom primijenjenom na stupac može prisiliti na više rada nego izravna usporedba raspona. Umjesto primjene funkcije datuma na svaku pohranjenu vremensku oznaku, izračunajte raspon u PHP-u i izravno usporedite stupac kada se time očuva značenje upita.

$start = new DateTimeImmutable('first day of this month 00:00:00');
$end = $start->modify('+1 month');

$stmt = $pdo->prepare(
    'SELECT id, created_at, total
     FROM orders
     WHERE account_id = :account_id
       AND created_at >= :start
       AND created_at < :end
     ORDER BY created_at DESC
     LIMIT 50'
);

$stmt->execute([
    'account_id' => $accountId,
    'start' => $start->format('Y-m-d H:i:s'),
    'end' => $end->format('Y-m-d H:i:s'),
]);

Korištenje poluotvorenog raspona, od uključivog početka do isključive sljedeće granice, izbjegava dvosmislene vrijednosti „kraja dana” i prirodno funkcionira s vremenskim oznakama koje uključuju djeliće sekunde.

Pronađite obrazac upita N+1 prije podešavanja pojedinačnih naredbi

Neka od najskupljih ponašanja baze podataka skrivaju se iza pojedinačno brzih upita. Krajnja točka može učitati 100 narudžbi, a zatim izvršiti jedan upit po narudžbi za učitavanje njezina kupca ili stavki. Svaki upit zasebno izgleda bezopasno. Zajedno stvaraju kašnjenje, pritisak na veze i nepotreban rad baze podataka.

Brojite upite po zahtjevu, a ne samo vrijeme po upitu. Ako stranica treba povezani zapis za svaku stavku, razmotrite učitavanje potrebnih odnosa u ograničenom broju upita ili vraćanje namjerno oblikovanog skupa rezultata. Najbolje rješenje ovisi o kardinalnosti i načinu na koji se rezultat koristi, ali cilj je dosljedan: ukloniti ponovljena mrežna putovanja bez stvaranja neupravljivog upita s mnogo dupliciranih podataka.

• Dohvaćajte samo stupce koje odgovor stvarno treba.
• Postavite razumne granice paginacije; izbjegavajte izvoz neograničene tablice putem web zahtjeva.
• Grupirajte identifikatore pri dohvaćanju poznate skupine povezanih zapisa.
• Učitavanje odnosa držite eksplicitnim kako buduće promjene ne bi neprimjetno ponovno uvele upite po retku.

Ovdje je korisna suzdržanost. Zamjena svakog upita jednim golemim spajanjem može otežati razumijevanje koda i proizvesti više podataka nego što je potrebno. Izmjerite ukupni oblik zahtjeva, a zatim odaberite najjednostavniju strategiju dohvaćanja koja drži broj upita i prenesene podatke pod kontrolom.

Odvojite vrijeme upita od svega što ga okružuje

Vrijeme SQL poziva izmjereno stvarnim satom može uključivati više od izvršavanja. PHP možda čeka vezu, baza podataka možda je blokirana zaključavanjem ili proces možda troši znatno vrijeme na hidrataciju objekata i serijalizaciju velikog JSON odgovora nakon dovršetka upita.

Jasno instrumentirajte granicu. Zabilježite naziv operacije, trajanje i sigurni otisak upita umjesto neselektivnog zapisivanja osjetljivih vrijednosti. Uparite vremena baze podataka s vremenima na razini zahtjeva i informacijama o pogreškama. To omogućuje razlikovanje dosljedno skupog plana od povremenog operativnog problema.

Pripremljene naredbe i dalje su važne za ispravnost i sigurnost, ali same po sebi nisu strategija performansi. Treba ih kombinirati s odgovarajućim indeksima, ograničenim veličinama rezultata i upravljanjem vezama koje odgovara modelu implementacije aplikacije.

Testirajte promjenu u odnosu na stvarno opterećenje

Popravci performansi zaslužuju istu disciplinu kao i funkcionalne promjene. Pokrenite izmijenjeni upit s reprezentativnom distribucijom podataka i parametrima. Potvrdite da poredak rezultata, paginacija i rubni slučajevi i dalje ispravno funkcioniraju. Ponovno provjerite plan nakon promjena sheme ili upita te usporedite vremena na razini zahtjeva umjesto da slavite jedno lokalno mjerenje.

U kontejneriziranim okruženjima uskladite migracije sheme, aplikacijski kod i konfiguraciju promatranja. Poboljšanje upita koje ovisi o novom indeksu nepotpuno je dok se migracija ne implementira pouzdano i dok ga produkcijska shema nema. Uvođenje koda koji pretpostavlja postojanje indeksa prije nego što je migracija dostupna može stvoriti upravo onu vrstu neočekivane regresije performansi koju je promjena trebala spriječiti.

Neka razumijevanje upita postane timska navika

Trajna korist nije zbirka pametnih indeksa. To je zajednička navika tretiranja rada baze podataka kao dijela dizajna aplikacije. Tijekom pregleda zapitajte se što upit vraća, koliko redaka može pregledati, koji ga indeks podržava i koliko ga često zahtjev izvršava. Kada trag prepozna usko grlo, pratite ga kroz plan upita, shemu, oblik podataka i pozivajući kod.

Profileri vam govore gdje gledati. Planovi upita, realistični ulazi i pažljiv dizajn aplikacije govore vam što promijeniti. Tako rad na PHP performansama prestaje biti lov na milisekunde i postaje jasnije razumijevanje sustava od kojeg tražite da obavi posao.