Problemi s performansama baze podataka rijetko se najavljuju urednim objašnjenjem. Pojavljuju se kao spor endpoint, red čekanja koji zaostaje, vremensko ograničenje tijekom vršnog prometa ili nadzorna ploča koja se doima neobjašnjivo tromom. Primamljiv odgovor jest dodati indeks, povećati ograničenje broja veza ili prijeći na snažniju infrastrukturu.

Te promjene mogu pomoći, ali samo su nagađanja dok ne možete vidjeti što baza podataka zapravo radi. Pragmatičan rad na performansama počinje dokazima: koji se upiti izvršavaju, koliko se često izvršavaju, koliko podataka obrađuju i gdje se troši vrijeme.

Započnite pitanjem koje stoji iza sporosti

„Baza podataka je spora” nije korisna dijagnoza. Baza podataka možda čeka disk, troši CPU na sortiranje redaka, obrađuje previše istodobnih veza ili jednostavno prima neučinkovit obrazac upita iz aplikacije.

Pretvorite nejasan simptom u pitanje koje je moguće testirati. Na primjer:

• Koja SQL naredba najviše utječe na latenciju zahtjeva?
• Je li jedan upit spor ili se izvršava stotinama puta po zahtjevu?
• Pregledava li upit daleko više redaka nego što ih vraća?
• Kasne li pisanja zbog zaključavanja ili zbog obrade transakcija na strani aplikacije?
• Pogoršavaju li se performanse samo kada se poveća istodobnost?

Ovakvo uokvirivanje sprječava preuranjene popravke. Indeks dizajniran za upit koji zapravo nije važan predstavlja trošak održavanja, a ne optimizaciju.

Upotrijebite zapisnik sporih upita kao provjeru stvarnosti

Za baze podataka kompatibilne s MySQL-om, zapisnik sporih upita jedna je od najpraktičnijih početnih točaka. Bilježi naredbe koje premašuju konfigurirani prag i može otkriti upite koji su istodobno skupi i česti.

Nizak prag koristan je tijekom usredotočene istrage, ali u produkciji ga treba pažljivo odabrati. Bilježenje svake naredbe može stvoriti nepotrebno opterećenje i veliku količinu podataka. Cilj je prepoznati značajne kandidate, a ne neograničeno prikupljati šum.

Kada imate kandidata za upit, nemojte ga procjenjivati samo prema njegovom pojedinačnom trajanju. Upit koji traje 20 milisekundi može biti štetniji od administrativnog izvješća koje traje jednu sekundu ako se prvi izvršava tisućama puta u minuti.

Tražite kombinaciju vremena izvršavanja, učestalosti poziva i korisničkih putanja na koje to utječe. Tu optimizacija obično donosi stvarnu vrijednost.

Pročitajte planove izvršavanja prije dodavanja indeksa

Plan izvršavanja objašnjava kako baza podataka namjerava dohvatiti i spojiti retke. U MySQL-u je EXPLAIN uobičajeni prvi alat:

EXPLAIN
SELECT id, title, published_at
FROM articles
WHERE author_id = 42
  AND status = 'published'
ORDER BY published_at DESC
LIMIT 20;

Izlaz nije presuda; on je model odabrane strategije. Posebno obratite pozornost na to pregledava li baza podataka velik broj redaka, koristi li očekivani indeks, stvara li privremenu tablicu ili izvodi li filesort. Ti signali trebaju kontekst. Filesort nije automatski pogrešan, a indeks nije automatski koristan.

Za ovaj upit, složeni indeks kao što je (author_id, status, published_at) može biti relevantan jer slijedi obrazac filtriranja i sortiranja. No treba ga provjeriti u odnosu na stvarni oblik upita i raspodjelu podataka. Redoslijed indeksa važan je, a indeks koji pomaže jednoj putanji čitanja može povećati trošak umetanja i ažuriranja.

Kada to podržavaju verzija baze podataka i operativna pravila, EXPLAIN ANALYZE može dodati stvarne informacije o izvršavanju. Upotrebljavajte ga promišljeno, osobito na produkcijskim sustavima, jer samo mjerenje izvršava upit.

Pronađite obrasce aplikacije koje SQL sam ne može pokazati

Alati za baze podataka prikazuju naredbe. Opservabilnost aplikacije pokazuje zašto te naredbe postoje. To je osobito važno u PHP aplikacijama koje koriste ORM ili sloj repozitorija, gdje praktičan pristup objektima može sakriti skupo ponašanje.

Klasičan je primjer obrazac upita N+1. Endpoint dohvaća popis narudžbi, a zatim pojedinačno učitava kupca za svaku narudžbu. Stranica može raditi savršeno s deset redaka, a postati skupa sa stotinama.

Mjerite broj upita i ukupno vrijeme provedeno u bazi podataka po zahtjevu. Zahtjev koji izvršava 80 brzih upita i dalje može biti sporiji, manje predvidljiv i teže skalabilan od onoga koji izvršava tri dobro dizajnirana upita.

Korisni signali na razini zahtjeva uključuju:

• ukupan broj upita;
• ukupno vrijeme provedeno čekajući bazu podataka;
• najsporiji pojedinačni upit;
• duplikate otisaka upita;
• vraćene retke u odnosu na pregledane retke, gdje je dostupno.

Praćenje je osobito vrijedno kada zahtjev prolazi kroz API-je, redove čekanja, predmemorije i više poziva baze podataka. Pomaže razlikovati spor upit baze podataka od vremena provedenog u čekanju veze, serijalizaciji odgovora ili pozivanju ovisne usluge.

Mjerite pritisak na veze i ponašanje zaključavanja

Nije svako kašnjenje baze podataka uzrokovano izvršavanjem upita. Iscrpljenost veza može učiniti zdrave upite sporima jer zahtjevi čekaju prije početka SQL-a. To se često događa kada radnici aplikacije, pozadinski poslovi i zakazani zadaci svaki održavaju vlastiti skup veza bez zajedničkog proračuna istodobnosti.

Pratite aktivne veze, veze na čekanju, pogreške povezivanja i trajanje neaktivnih veza. U kontejneriziranim implementacijama također uzmite u obzir učinke umnožavanja: povećanje broja PHP radnika ili Docker replika može pomnožiti broj mogućih veza s bazom podataka brže nego što se očekuje.

Za sustave s mnogo pisanja pregledajte čekanja na zaključavanje i trajanje transakcija. Transakcija koja drži zaključavanja dok obavlja HTTP pozive, složen rad aplikacije ili interakciju korisnika predstavlja problem dizajna. Neka transakcije budu uske: najprije provjerite što možete, obavite potreban rad s bazom podataka, a zatim se odmah potvrđujte.

Ponovni pokušaji zaslužuju jednaku pažnju. Ponovni pokušaj prolaznog zastoja može biti razuman kada je operaciju sigurno ponoviti. Ponovni pokušaj svake pogreške baze podataka nije. Ponovni pokušaj mora imati ograničenje, odgodu, opservabilnost i idempotentnost tamo gdje bi dvostruko izvršavanje moglo prouzročiti štetu.

Usporedno mjerite tijek rada, a ne samo upit

Upit kopiran u konzolu može izgledati brzo, dok stvarni endpoint ostaje spor. Produkcijsko ponašanje uključuje varijacije parametara, stanje predmemorije, mrežnu latenciju, serijalizaciju, istodobni promet i rast podataka.

Upotrebljavajte reprezentativne podatke i realistične putanje zahtjeva. Usporedite mjerenja prije i poslije u istim uvjetima. Zabilježite promjenu koju ste napravili, očekivani ishod i opaženi rezultat. Ako indeks smanji latenciju jednog endpointa, ali drugdje uzrokuje neprihvatljivo opterećenje pri pisanju, taj bi kompromis trebao biti vidljiv, a ne slučajan.

Praktična petlja optimizacije jednostavna je:

1. Prepoznajte simptom vidljiv korisniku ili operativno značajan simptom.
2. Izmjerite odgovorni zahtjev, posao ili SQL obrazac.
3. Pregledajte plan izvršavanja i okolno ponašanje aplikacije.
4. Napravite jednu ciljanu promjenu.
5. Izmjerite ponovno te zadržite ili poništite promjenu na temelju dokaza.

Neka znanje o performansama postane dio sustava

Najjači timovi za baze podataka ne oslanjaju se na herojsko otklanjanje pogrešaka svaki put kada latencija poraste. Oni u redovite operacije ugrađuju mali, trajan skup signala: vidljivost sporih upita, praćenje zahtjeva, metrike veza, stope pogrešaka i upozorenja povezana s utjecajem na korisnike.

Promjene sheme također tretiraju kao promjene softvera. Novi indeksi, migracije, prepisivanja upita i prilagodbe skupa veza zaslužuju pregled, testiranje, planiranje uvođenja i put za vraćanje promjena. Rad na performansama postaje sigurniji kada je ponovljiv.

Zapamtite ovo: ugađanje baze podataka nije natjecanje u pisanju domišljatog SQL-a ili prikupljanju indeksa. To je disciplina zamjene pretpostavki mjerenjima. Kada možete vidjeti posao koji vaša baza podataka obavlja, sljedeća odluka postaje mnogo manje tajanstvena — i mnogo je vjerojatnije da će pomoći.