Пет водещи съображения за дизайна на индекс на база данни в SQL Server

Индексите на базата данни се използват за ускоряване на различни операции с таблици. Въпреки това, преди да създадете индекс, важно е да знаете дали наистина имате нужда от индекс? И ако трябва да създадете индекс, кои са важните моменти, които трябва да имате предвид? Това е мястото, където идва дизайнът на индекса на базата данни.

Тази статия има за цел да отговори на тези въпроси относно дизайна на индекс на база данни и да хвърли малко светлина върху някои от основните съображения, които разработчикът на база данни трябва да вземе предвид при проектирането на индекс.

1. Размер на таблицата

Първият въпрос, който разработчикът на база данни трябва да зададе, преди да създаде индекс, е дали таблицата е достатъчно голяма, за да използва ефективно индексите. Ако размерът на таблицата е малък, SQL Server може да сканира цялата таблица по-бързо, отколкото да търси таблицата чрез индекс. Индексите в такъв случай нямат никаква полза и създават допълнителни разходи при извършване на операции с база данни.

2. Видове колони

Индексите трябва да се създават в колона с първичен ключ или всяка колона, която съдържа уникални стойности и има ограничение NOT NULL. Освен това е препоръчително да създавате индекси върху числови колони, тъй като числовите колони са склонни да имат по-уникални стойности в сравнение с нечисловите колони. Лошият дизайн на индекса на базата данни използва индекси на колони, които имат много малко уникални записи и може да доведе до много времеемки заявки.

Помислете за таблица с име Patients, която съдържа стотици хиляди записи. Таблицата с пациенти ще съдържа колона, наречена „Пол“, която може да има само две уникални стойности „Мъж“ и „Женски“. Ако създадете индекс в „Колона Пол“, записите ще бъдат сортирани във възходящ или низходящ азбучен ред.

Така че, ако имате милион записи в таблицата на пациентите и броят на пациентите от мъжки и женски пол е равен, в индекса първите половин милион записи ще имат пол „Жен“, а вторият половин милион ще има пол „Мъжки“. Сега, ако искате да търсите жена, която съществува на 490 000-ия ред от женските записи, SQL Server Engine ще трябва да сканира 490 000 записа. От друга страна, с уникални числови стойности търсенето може да бъде изключително бързо, тъй като индексите на SQL Server се съхраняват под формата на B + дървета и така числовите стойности в възлите на дървото могат да ускорят операциите на базата данни.

3. Брой индекси

Официално можете да създадете един клъстериран индекс и толкова неклъстерирани индекси, колкото искате за всяка таблица на базата данни. Въпреки това, добър дизайн на индекси на база данни е да се създаде един клъстериран индекс и само ограничен брой абсолютно необходими неклъстерирани индекси. Създаването на твърде много неклъстерирани индекси всъщност може да забави операциите за актуализиране и вмъкване, тъй като когато записът се актуализира или вмъкне и стойността на колона се промени, всички свързани индекси трябва да бъдат актуализирани.

Помислете за сценарий, при който имаме два неклъстерирани индекса, като първият индекс сортира записите по възраст, а вторият индекс сортира записите както по пол, така и по възраст.

Ето първия индекс:

А ето и второто:

Сега, ако запис на възраст 40 трябва да бъде актуализиран до 15 години по някаква причина, тогава първият индекс ще трябва да бъде актуализиран, за да премести записа от 7-ма позиция (40) на втора позиция, за да запази индекса сортиран. По същия начин във втория индекс записът в 4-ти индекс ще бъде преместен във втория индекс. Трябва да се направят много размествания. Ето защо е разумно да поддържате броя на индексите до минимум за колоните, които се актуализират редовно, когато мислите за дизайна на индекса на базата данни. Също така една колона не трябва да се използва в множество неклъстерирани индекси.

4. Местоположение за съхранение на индекси

Местоположението за съхранение на индекс може да повлияе на производителността на заявките, които използват индекса, и така също е част от добрия дизайн на индекса на базата данни. По подразбиране клъстериран индекс се съхранява в същата файлова група като таблицата, върху която е създаден индексът. За неклъстерирани индекси, индексът може да се съхранява в една и съща файлова група или в различни файлови групи, обхващащи множество дискови устройства. Производителността на заявките на неклъстерирани индекси може да бъде значително подобрена чрез съхраняване на неклъстерирани индекси на множество дискови устройства. Това е така, защото входно/изходната производителност на заявката ще бъде подобрена в резултат на разпределението на данните в различни области на устройството.

Местоположението за съхранение на индекси по подразбиране може също да бъде променено чрез задаване на стойност за опцията FILLFACTOR. Тъй като индексите се съхраняват физически под формата на B+ дървета, индексните данни се съхраняват на листовите страници. С опцията FILLFACTOR можете да зададете процента на страниците на ниво лист, които да бъдат запълнени. Например, ако зададете стойността на FILLFACTOR на 70%, само 70% от общото пространство на страницата на ниво лист ще бъде запълнено от индексни данни. Останалите 30% ще бъдат оставени за автоматично увеличаване на индексните данни в бъдеще.

5. Типове индекси

Друго изключително важно съображение при проектирането на индекс на база данни е типът на индекса, който да се използва. В по-ранна статия (добавете връзка към статията „Кога да се използва клъстериран или неклъстериран индекс“) обясних разликата между клъстерирани и неклъстерирани индекси. Обясних също какво представляват и как могат да се използват. Решението дали да изберете клъстериран или неклъстерен индекс е от решаващо значение и трябва да бъде внимателно обмислено.

Следните точки трябва да имате предвид, когато решавате кой тип индекс да изберете.

1. За колоните, които се използват в заявки SELECT/JOIN/GROUP BY/BETWEEN, използвайте клъстерирани индекси.
2. Използвайте неклъстерирани индекси за колони, където искате да извлечете стойности само от тази конкретна колона, а не от другите колони на същия ред. Заявките SELECT, които извличат множество записи с помощта на неклъстериран индекс, могат да бъдат бавни, тъй като машината на SQL Server първо търси стойностите на колоните, върху които е създаден индексът, а след това използвайки препратката на реда за стойността на колоната, записите от действителните таблици на базата данни се извличат .
3. За колоните, които често се подлагат на операции INSERT и UPDATE, използвайте неклъстериран индекс. Уверете се, че не използвате една колона в множество неклъстерирани индекси, тъй като това може да забави заявките за актуализиране. Клъстерираните индекси могат да бъдат бавни за операции INSERT/UPDATE, тъй като пълният ред трябва да бъде актуализиран, а не само стойност на една колона, както е при неклъстерираните индекси.
4. Тъй като можете да създадете само един клъстериран индекс, в техния случай, когато имате нужда от няколко индекса, използвайте неклъстерирани индекси. Ако обаче дисковото пространство е основен проблем, сведете броя на неклъстерираните индекси до минимум.

Други съображения

Въпреки че това са петте най-важни части от дизайна на индекса на базата данни, те не са всичко. Важно е да посочите правилния ред на колоните в индексите. Като правило, колоните, които се използват за вземане на решения в клаузи WHERE и условия като по-голямо от (>), по-малко от (<) и т.н., трябва да се поставят преди колоните, които не са включени в тези клаузи. В случай на множество колони в клаузата WHERE, най-отличителните имена на колони трябва да бъдат споменати най-рано в дефиницията на индекса.

Освен дизайна на индекса на базата данни, дизайнът на заявки също играе важна роля за ефективното използване на дизайна на индекса. За оптимизирана поддръжка на индекса вместо да пишете множество заявки, които работят с малък брой редове, опитайте се да пишете по-малко заявки, които засягат по-голям брой редове в таблицата.

Заключение

Тази статия обяснява някои от основните съображения, които разработчикът на база данни трябва да вземе предвид, когато разглежда дизайна на индекса на базата данни. Статията също така обяснява обосновката на тези съображения и съдържа допълнителни предложения, за да се уверите, че дизайнът на индекса на вашата база данни е ефективен.