Većina problema s performansama baze podataka nije tajanstvena. To su odluke u dizajnu koje su ostale nevidljive dok je sustav bio malen: krajnja točka koja učitava daleko više podataka nego što joj je potrebno za odgovor, koristan indeks koji nikada nije dodan, pozadinski zadatak koji se natječe s prometom korisnika ili API ugovor koji tiho pretvara jedan upit u stotinu.

To su dobre vijesti. To znači da je odgovor rijetko „potražite čarobnu postavku baze podataka”. Trajno rješenje jest razumjeti radno opterećenje, pristup podacima učiniti namjernim i dati bazi podataka oblik koji može učinkovito izvršavati.

Počnite sa sporom putanjom, a ne sa sumnjivim bugom

Spora stranica ne dokazuje da je baza podataka kriva. Aplikacijski kod, mrežni pozivi, serijalizacija, promašaji predmemorije i preopterećeni radnici mogu stvoriti isti simptom. Izmjerite cijeli zahtjev, a zatim utvrdite upite koji značajno pridonose vremenu ili opsegu.

Za svaku važnu krajnju točku postavite nekoliko izravnih pitanja: Koliko upita izvršava? Koliko redaka svaki upit pregledava i vraća? Koliko se često krajnja točka poziva? Je li latencija stabilna ili se pogoršava kako tablica raste? Ta pitanja pretvaraju neodređenu pritužbu u inženjerski problem s jasnim granicama.

Dnevnici upita i mjerenje vremena na razini aplikacije korisni su jer otkrivaju obrasce koje jedan ručno pokrenut upit može sakriti. Upit koji jednom traje 20 milisekundi i dalje može biti skup ako se izvršava 50 puta po zahtjevu. S druge strane, povremeni analitički upit može biti prihvatljiv čak i kada je sporiji, pod uvjetom da je izoliran od interaktivnog prometa.

Indeksi se odnose na putanje pristupa, a ne na ukras

Indeks pomaže kada odgovara načinu na koji baza podataka filtrira, spaja ili sortira podatke. Nasumično dodavanje indeksa može poskupiti upise i ostaviti stvarno usko grlo netaknutim. Svako umetanje, ažuriranje i brisanje možda mora održavati svaki relevantni indeks.

Razmotrite krajnju točku koja prikazuje nedavne plaćene narudžbe za jedan račun:

SELECT id, total, created_at
FROM orders
WHERE account_id = ?
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

Složeni indeks koji počinje s account_id i status, nakon kojih slijedi created_at, usklađen je s ovim obrascem pristupa. Točno najbolji indeks ovisi o sustavu baze podataka i radnom opterećenju, ali načelo je stabilno: filtri jednakosti općenito sužavaju pretragu prije nego što uvjeti raspona i sortiranje postanu korisni.

Upotrijebite alate baze podataka za plan upita kako biste provjerili pretpostavke. Plan koji pretražuje veliku tablicu, stvara privremeno sortiranje ili pregledava znatno više redaka nego što vraća zaslužuje pažnju. Nemojte stati na „indeks postoji”. Potvrdite da ga optimizator može i doista koristi za upit koji stvarno isporučujete.

Učinite predikate prilagođenima indeksima

Indeksi mogu biti onemogućeni inače bezazlenim izrazima. Primjena funkcije na indeksirani stupac u filtru može spriječiti učinkovito pretraživanje. Primjerice, filtriranje funkcijom za izdvajanje datuma može zahtijevati više rada nego filtriranje prema izračunatom rasponu datuma.

-- Manje prilagođeno indeksu created_at
WHERE DATE(created_at) = '2026-08-17'

-- Obično jednostavnije za upotrebu s indeksom
WHERE created_at >= '2026-08-17 00:00:00'
  AND created_at < '2026-08-18 00:00:00'

Isti oprez vrijedi za pretrage s vodećim zamjenskim znakovima, implicitne pretvorbe tipova i široke uvjete OR. To nisu zabranjeni konstrukti; oni su znakovi da treba pregledati plan i razmotriti drukčiju strategiju pristupa podacima.

Uklonite slučajno umnožavanje upita

Klasični problem upita N+1 i dalje je čest jer objektno orijentirani kod može učiniti da izgleda prirodno. Učitajte 50 narudžbi, zatim lijeno učitajte kupca za svaku narudžbu, i jedna krajnja točka može postati 51 povratno putovanje do baze podataka. Dodajte povezane stavke ili dozvole i broj brzo raste.

Riješite to namjerno. Dohvatite potrebne odnose u skupinama, upotrijebite spajanje kada daje pravi oblik rezultata ili prikupite strane ključeve i dohvatite povezane zapise jednim dodatnim upitom. Cilj nije uvijek „jedan upit”. Cilj je malen, predvidljiv broj upita koji vraćaju samo podatke potrebne za odgovor.

Budite jednako oprezni prema suprotnoj krajnosti: jednom golemom spajanju koje ponavlja podatke nadređenog zapisa za svaki redak podređenog zapisa, troši memoriju i postaje teško razumjeti. Za detaljan API odgovor, dva ili tri usmjerena upita mogu biti jasnija i jeftinija od duboko spojenog skupa rezultata. Performanse i održivost često se zajedno poboljšavaju kada su granice podataka jasne.

Paginacija je ugovor baze podataka

Paginacija s pomakom je praktična:

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

Ali veliki pomaci mogu prisiliti bazu podataka da prođe pokraj mnogih redaka prije vraćanja stranice. Također se loše ponašaju kada novi zapisi pristižu između zahtjeva. Za velike skupove podataka koji se često pregledavaju, paginacija temeljena na kursoru obično je bolji ugovor.

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

Kursor bi trebao uključivati stabilan razrješivač izjednačenja, kao što je id. Odgovarajući indeks mora podržavati odabrani redoslijed. To je mala odluka u dizajnu API-ja s velikim operativnim učinkom: izbjegava sve skuplje duboke stranice i klijentima pruža dosljednije kretanje kroz podatke.

Odvojite transakcijski rad od skupog rada

Transakcije štite ispravnost, ali duge transakcije mogu držati zaključavanja i povećati sukobljavanje. Neka ostanu usmjerene: provjerite potrebno stanje, zapišite potrebne zapise i potvrdite transakciju. Izbjegavajte izvođenje sporih HTTP poziva, obrade velikih datoteka ili širokih izvještajnih upita dok je transakcija otvorena.

Pozadinski zadaci pomažu, ali nisu automatski bezopasni. Radnik koji ažurira milijune redaka u jednoj transakciji može se natjecati s produkcijskim zahtjevima jednako učinkovito kao spora web krajnja točka. Obrađujte velike zadatke održavanja u ograničenim skupinama, učinite ponovne pokušaje idempotentnima i pratite pritisak koji stvaraju na istim tablicama koje koristi interaktivni promet.

• Upotrijebite jedinstveni poslovni ključ ili zabilježeni identifikator operacije kada bi ponovni pokušaji mogli stvoriti duplicirani rad.
• Potvrđujte transakcije u upravljivim skupinama kako bi zaključavanja i opseg vraćanja ostali ograničeni.
• Primijenite odgodu kada su ovisni sustavi ili baza podataka pod pritiskom.
• Kada je moguće, planirajte zahtjevno izvještavanje ili održavanje izvan poznatih vrhunaca prometa.

Predmemorirajte rezultate uz priču o isteku

Predmemoriranje je vrijedno kada su ponovljena čitanja skupa i kada su prihvatljivi neznatno zastarjeli podaci. Ono nije zamjena za razumijevanje neučinkovitog upita. Predmemorija može sakriti loš obrazac pristupa dok ga događaj hladne predmemorije, greška invalidacije ili novi obrazac prometa ponovno ne otkrije.

Prije predmemoriranja definirajte što predmemorirana vrijednost predstavlja, kako istječe i što se događa nakon upisa. Kratkotrajna predmemorija za javni agregat ima drukčije zahtjeve ispravnosti od predmemoriranog stanja računa. Ako je invalidacija teška, razmotrite može li značajka tolerirati svježinu temeljenu na vremenu, verzionirane ključeve ili unaprijed izračunati model čitanja.

Dizajnirajte za radno opterećenje koje očekujete

Brzina baze podataka nije završni korak optimizacije. Ona je dio dizajna API-ja, dizajna sheme i operativnog dizajna. Dobra krajnja točka definira ograničen odgovor. Dobra shema odražava upite koji su važni. Dobra implementacija uključuje sigurne migracije, mogućnost promatranja i plan vraćanja za promjene koje mijenjaju ponašanje upita.

Najkorisnija je navika svaki spori upit tretirati kao povratnu informaciju o dizajnu sustava. Izmjerite ga u kontekstu, pregledajte njegov put izvršavanja, smanjite nepotreban rad i provjerite poboljšanje u realističnim uvjetima. Prestanite loviti bugove baze podataka kao izolirana iznenađenja. Dizajnirajte predvidljive putanje pristupa, a baza podataka postat će ono što bi trebala biti: pouzdan dio sustava, a ne njegova stalna hitna situacija.