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

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

Започнете со прашањето зад бавноста

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

Претворете нејасен симптом во прашање што може да се тестира. На пример:

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

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

Користете го дневникот на бавни прашања како проверка на реалноста

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

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

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

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

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

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

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

Излезот не е пресуда; тој е модел на избраната стратегија. Обрнете особено внимание на тоа дали базата на податоци испитува голем број редови, користи очекуван индекс, создава привремена табела или извршува filesort. На овие сигнали им е потребен контекст. Filesort не е автоматски погрешен, а индексот не е автоматски корисен.

За ова прашање, композитен индекс како (author_id, status, published_at) може да биде релевантен бидејќи го следи образецот на филтрирање и подредување. Но треба да се потврди во однос на вистинскиот облик на прашањето и распределбата на податоците. Редоследот на индексот е важен, а индекс што помага на една патека за читање може да ја зголеми цената на вметнувања и ажурирања.

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

Пронајдете ги обрасците во апликацијата што SQL сам не може да ги покаже

Алатките за бази на податоци покажуваат наредби. Набљудливоста на апликацијата покажува зошто постојат тие наредби. Ова е особено важно во PHP апликации што користат ORM или слој на складиште, каде што практичниот пристап до објекти може да скрие скапо однесување.

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

Мерете го бројот на прашања и вкупното време во базата на податоци по барање. Барање што извршува 80 брзи прашања сè уште може да биде побавно, помалку предвидливо и потешко за скалирање од барање што извршува три добро дизајнирани прашања.

Корисни сигнали на ниво на барање вклучуваат:

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

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

Мерете го притисокот од конекции и однесувањето на заклучувањата

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

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

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

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

Тестирајте го целиот работен тек, не само прашањето

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

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

Практичен циклус на оптимизација е едноставен:

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

Направете го знаењето за перформансите дел од системот

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

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

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