Повеќето проблеми со перформансите на базата на податоци не се мистериозни. Тие се одлуки во дизајнот што останале невидливи додека системот бил мал: крајна точка што вчитува многу повеќе податоци отколку што му се потребни на нејзиниот одговор, корисен индекс што никогаш не бил додаден, заднинска задача што се натпреварува со сообраќајот на клиентите или API договор што тивко претвора едно барање во сто.

Тоа е добра вест. Тоа значи дека одговорот ретко е „барајте магично поставување на базата на податоци“. Трајниот одговор е да се разбере оптоварувањето, пристапот до податоците да се направи намерен и на базата на податоци да ѝ се даде форма што може ефикасно да ја извршува.

Започнете со бавната патека, а не со сомнителната грешка

Бавна страница не докажува дека базата на податоци е виновна. Кодот на апликацијата, мрежните повици, серилизацијата, промашувањата во кешот и преоптоварените работници можат да создадат ист симптом. Измерете го целото барање, а потоа идентификувајте ги барањата што придонесуваат значително време или обем.

За секоја важна крајна точка, поставете неколку директни прашања: Колку барања извршува? Колку редови испитува и враќа секое барање? Колку често се повикува крајната точка? Дали латентноста е стабилна или се влошува како што расте табелата? Овие прашања претвораат нејасна жалба во инженерски проблем со граници.

Дневниците на барања и мерењето на ниво на апликација се корисни бидејќи откриваат обрасци што едно рачно извршено барање може да ги скрие. Барање што еднаш трае 20 милисекунди сепак може да биде скапо ако се извршува 50 пати по барање. Спротивно на тоа, повремено аналитичко барање може да биде прифатливо дури и кога е побавно, под услов да е изолирано од интерактивниот сообраќај.

Индексите се за патеки на пристап, не за декорација

Индексот помага кога одговара на начинот на кој базата на податоци филтрира, спојува или подредува податоци. Слепото додавање индекси може да ги направи запишувањата поскапи и да го остави вистинското тесно грло недопрено. Секое вметнување, ажурирање и бришење можеби ќе треба да го одржува секој релевантен индекс.

Разгледајте крајна точка што ги прикажува неодамнешните платени нарачки за една сметка:

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

Композитен индекс што започнува со account_id и status, по кои следи created_at, се усогласува со овој образец на пристап. Точниот најдобар индекс зависи од механизмот на базата на податоци и оптоварувањето, но принципот е стабилен: филтрите за еднаквост генерално го стеснуваат пребарувањето пред условите за опсег и подредувањето да станат корисни.

Користете ги алатките на базата на податоци за планови на барања за да ги потврдите претпоставките. План што скенира голема табела, создава привремено подредување или испитува многу повеќе редови отколку што враќа заслужува внимание. Не застанувајте на „индексот постои“. Потврдете дека оптимизаторот може и навистина го користи за барањето што навистина го испорачувате.

Направете ги предикатите погодни за индекси

Индексите може да бидат оневозможени од изрази што инаку изгледаат невино. Примената на функција врз индексирана колона во филтер може да спречи ефикасно пребарување. На пример, филтрирањето со функција за извлекување датум може да наметне повеќе работа отколку филтрирањето според пресметан опсег на датуми.

-- Помалку погодно за индекс на created_at
WHERE DATE(created_at) = '2026-08-17'

-- Вообичаено полесно за користење со индекс
WHERE created_at >= '2026-08-17 00:00:00'
  AND created_at < '2026-08-18 00:00:00'

Истата претпазливост важи за пребарувања со џокер-знак на почетокот, имплицитни конверзии на типови и широки OR услови. Овие не се забранети конструкции; тие се сигнали да се испита планот и да се разгледа поинаква стратегија за пристап до податоци.

Елиминирајте го случајното умножување на барања

Класичниот проблем со N+1 барања сè уште е чест бидејќи објектно-ориентираниот код може да направи да изгледа природно. Вчитајте 50 нарачки, а потоа мрзеливо вчитајте го клиентот за секоја нарачка, и една крајна точка може да стане 51 повратно патување до базата на податоци. Додадете поврзани ставки или дозволи и бројот брзо расте.

Поправете го ова намерно. Преземете ги потребните врски во серии, користете спојување кога создава правилна форма на резултатот или соберете ги странските клучеви и преземете ги поврзаните записи со едно дополнително барање. Целта не е секогаш „едно барање“. Целта е мал, предвидлив број барања што ги враќаат само податоците потребни за одговорот.

Бидете подеднакво внимателни и со спротивната крајност: едно огромно спојување што ги повторува родителските податоци за секој ред на дете, троши меморија и станува тешко за разбирање. За детален API одговор, две или три фокусирани барања може да бидат појасни и поевтини од длабоко споен сет на резултати. Перформансите и одржливоста често се подобруваат заедно кога границите на податоците се експлицитни.

Пагинацијата е договор со базата на податоци

Пагинацијата со отстапување е практична:

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

Но големите отстапувања може да ја натераат базата на податоци да помине покрај многу редови пред да ја врати страницата. Тие исто така се однесуваат лошо кога меѓу барањата пристигнуваат нови записи. За големи множества на податоци што често се прелистуваат, пагинацијата базирана на курсор обично е подобар договор.

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

Курсорот треба да содржи стабилен разрешувач на нерешени случаи, како што е id. Соодветниот индекс мора да го поддржува избраниот редослед. Ова е мала одлука во дизајнот на API со голем оперативен ефект: избегнува сè поскапи длабоки страници и им овозможува на клиентите подоследно движење низ записите.

Одделете ја трансакциската работа од скапата работа

Трансакциите ја штитат исправноста, но долгите трансакции можат да задржат заклучувања и да ја зголемат конкуренцијата. Одржувајте ги фокусирани: проверете ја потребната состојба, запишете ги потребните записи и потврдете. Избегнувајте извршување бавни HTTP повици, обработка на големи датотеки или широки барања за известување додека трансакцијата е отворена.

Заднинските задачи помагаат, но не се автоматски безопасни. Работник што ажурира милиони редови во една трансакција може да се натпреварува со продукциските барања исто толку ефикасно како бавна веб-крајна точка. Обработувајте големи задачи за одржување во ограничени серии, направете ги повторните обиди идемпотентни и следете го притисокот што го вршат врз истите табели што ги користи интерактивниот сообраќај.

• Користете единствен деловен клуч или зачуван идентификатор на операција кога повторните обиди би можеле да создадат дупликатна работа.
• Потврдувајте во управливи серии за заклучувањата и опсегот на враќање да останат ограничени.
• Применете повлекување кога зависните системи или базата на податоци се под притисок.
• Закажете тешко известување или одржување надвор од познатите врвови на сообраќај, кога е можно.

Кеширајте ги резултатите со приказна за истекување

Кеширањето е вредно кога повторените читања се скапи и малку застарени податоци се прифатливи. Тоа не е замена за разбирање на неефикасно барање. Кешот може да скрие лош образец на пристап сè додека настан со ладен кеш, грешка при поништување или нов образец на сообраќај повторно не го открие.

Пред кеширање, дефинирајте што претставува кешираната вредност, како истекува и што се случува по запишување. Краткотраен кеш за јавен агрегат има поинакви барања за исправност од кеширано салдо на сметка. Ако поништувањето е тешко, разгледајте дали функцијата може да толерира свежина заснована на време, верзирани клучеви или претходно пресметан модел за читање.

Дизајнирајте за оптоварувањето што очекувате да го имате

Брзината на базата на податоци не е последен чекор на оптимизација. Таа е дел од дизајнот на API, дизајнот на шемата и оперативниот дизајн. Добра крајна точка дефинира ограничен одговор. Добра шема ги одразува барањата што се важни. Добро распоредување вклучува безбедни миграции, набљудливост и план за враќање на промените што го менуваат однесувањето на барањата.

Најкорисната навика е секое бавно барање да се третира како повратна информација за дизајнот на системот. Измерете го во контекст, испитајте ја неговата патека на извршување, намалете ја непотребната работа и потврдете го подобрувањето во реалистични услови. Престанете да ги бркате грешките во базата на податоци како изолирани изненадувања. Дизајнирајте предвидливи патеки на пристап, и базата на податоци ќе стане она што треба да биде: сигурен дел од системот наместо негова постојана итна состојба.