Подобряване на най-добрите практики за ефективността на базата данни
Ние от 1cloud говорим много за собствения си опит при работа с доставчик на виртуална инфраструктура и тънкостите при организирането на вътрешни процеси. Днес решихме да поговорим малко за оптимизацията на базата данни.
Много СУБД са способни не само да съхраняват и управляват данни, но и да изпълняват код на сървъра. Съхранените процедури и задействания са примери за това. Само една операция за промяна на данни обаче може да стартира няколко задействания и съхранени процедури, които от своя страна ще „събудят“ още няколко.
Пример е каскадно изтриване в бази данни на SQL, където изключването на един ред в таблица променя много други свързани записи.
Очевидно е, че трябва внимателно да използвате разширената функционалност, за да не зареждате сървъра, защото всичко това може да повлияе на производителността на клиентските приложения, използващи тази база данни.
Погледнете графиката по-долу. Той показва резултатите от извършване на тестване на натоварване на приложение, когато броят на потребителите (синя графика), работещи с базата данни, постепенно се увеличава до 50. Броят на заявките (оранжев), които системата може да обработи, бързо достига своя максимум и спира да расте, докато времето за реакция (жълто) постепенно се увеличава.
Когато работите с големи бази данни, дори и най-малката промяна може да има сериозно въздействие върху производителността, както положително, така и отрицателно. В средни до големи организации администраторът е отговорен за настройването на базите данни, но често разработчиците са отговорни за тези задачи.
Ето защо по-долу ще дадем няколко практически съвета, които да помогнат за подобряване на производителността на SQL бази данни.
Използвайте индекси
Индексирането е ефективен начин за настройка на вашата база данни и често се пренебрегва по време на разработката. Индексът ускорява заявките, като осигурява бърз достъп до редове данни в таблица, подобно на това как индексът в книга ви помага бързо да намерите информацията, която искате.
Например, ако създадете индекс на първичен ключ и след това търсите ред данни, като използвате стойностите на първичния ключ, SQL Server първо намира стойността на индекса и след това го използва за бързо намиране на реда с данни. Без индекс ще бъде извършено пълно сканиране на всички редове на таблици и това е загуба на ресурси.
Трябва обаче да се отбележи, че ако вашите таблици са „бомбардирани“ с методите INSERT, UPDATE и DELETE, индексирането трябва да се предприема с повишено внимание - това може да доведе до влошаване на производителността, тъй като след извършване на горните операции, всички индекси трябва да бъдат променени.
Освен това, когато голям брой редове (например повече от един милион) трябва да бъдат добавени към таблица наведнъж, DBA често нулират индексите, за да ускорят процеса на вмъкване (индексите се създават отново след вмъкването). Индексирането е обширна и интересна тема и краткото описание не е достатъчно, за да започнете. Повече информация по тази тема можете да намерите тук.
Не използвайте цикли с много итерации
Представете си ситуация, когато 1000 заявки идват последователно във вашата база данни:
Не се препоръчва да пишете такива цикли. Примерът по-горе може да бъде повторен, като се използва един INSERT или UPDATE с множество параметри:
ВЪВЕЖДАНЕ В ИМЕ на Име на таблица (A, B, C) СТОЙНОСТИ (1,2,3), (4,5,6), (7,8,9)
АКТУАЛИЗИРАНЕ ИМЕ НА ТАБЛИЦАТА A = СЛУЧАЙ B
КОГА 1 ТОГАВА "НОВА СТОЙНОСТ"
КОГА 2 ТОГАВА "НОВА СТОЙНОСТ 2"
КОГА 3 ТОГАВА "НОВА СТОЙНОСТ 3"
КРАЙ
КЪДЕ B в (1,2,3)
Уверете се, че клаузата WHERE не замества дублирани стойности. Тази проста оптимизация може да ускори изпълнението на SQL заявката, като намали броя на актуализираните редове от хиляди на стотици. Пример за проверка:
АКТУАЛИЗИРАНЕ ИМЕ НА ТАБЛИЦАТА
КОМПЛЕКТ A = @VALUE
КЪДЕТО
B = "ВАШЕТО СЪСТОЯНИЕ"
И A <> @VALUE - ВАЛИДАЦИЯ
Избягвайте корелирани подзаявки
Корелирана подзаявка е подзаявка, която използва стойностите на родителската заявка. Изпълнява се ред по ред, веднъж за всеки ред, върнат от външната (родителска) заявка, което забавя скоростта на базата данни. Ето един прост пример за корелирана подзаявка: