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

Корисното прашање не е едноставно: „Кое барање е бавно?“ Туку: „Зошто на ова барање му е потребно толку работа за да го врати овој резултат?“ Таа промена ја претвора работата на перформансите од круг на нагаѓања во повторлива инженерска практика.

Профилирањето го наоѓа местото; плановите за барања го објаснуваат проблемот

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

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

За системи компатибилни со MySQL, проверете репрезентативна изјава со 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;

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

Прашајте каква работа мора да изврши базата на податоци

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

Разгледајте честа крајна точка: неодамнешни нарачки за сметка, подредени според времето на создавање. Индекс обликуван околу account_id и created_at може заедно да ги поддржи филтрирањето и подредувањето. Индекс само на created_at сè уште може да ја остави базата на податоци да прегледува многу редови што припаѓаат на други сметки.

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

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

$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'),
]);

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

Пронајдете го образецот на N+1 барања пред да подесувате поединечни изјави

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

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

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

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

Одделете го времето на барањето од сè околу него

Времето по ѕиден часовник на SQL-повик може да вклучува повеќе од извршување. PHP можеби чека конекција, базата на податоци може да биде блокирана од заклучување или процесот може да троши значително време за хидрирање објекти и сериски да обработува голем JSON-одговор откако барањето ќе заврши.

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

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

Тестирајте ја промената со реалното оптоварување

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

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

Претворете го разбирањето на барањата во тимска навика

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

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