Трудно е да се каже това по-накратко от SQL Server MVP Брад Макгихи:
Като практическо правило всяка таблица трябва да има клъстериран индекс. Като цяло, но не винаги, клъстерираният индекс трябва да бъде в колона, която монотонно се увеличава – като колона за идентичност или някаква друга колона, където стойността се увеличава – и е уникална. В много случаи първичният ключ е идеалната колона за клъстериран индекс.
BOL отразява това мнение:
С малки изключения всяка таблица трябва да има клъстериран индекс.
Причините за това са много и се основават основно на факта, че клъстериран индекс физически подрежда данните ви в хранилището .
-
Ако вашият клъстериран индекс е в една колона, монотонно се увеличава, вмъкванията се появяват в ред на вашето устройство за съхранение и разделянето на страници няма да се случи.
-
Клъстерираните индекси са ефективни за намиране на конкретен ред, когато индексираната стойност е уникална, като например общият модел на избор на ред въз основа на първичния ключ.
-
Клъстерираният индекс често позволява ефективни заявки към колони, които често се търсят за диапазони от стойности (
между,> и др.). -
Групирането може да ускори заявките, при които данните обикновено се сортират по конкретна колона или колони.
-
Клъстериран индекс може да бъде преустроен или реорганизиран при поискване, за да се контролира фрагментацията на таблицата.
-
Тези предимства могат дори да се прилагат към изгледи.
Може да не искате да имате клъстериран индекс на:
-
Колони, които имат чести промени в данните, тъй като SQL Server трябва физически да пренареди данните в хранилището.
-
Колони, които вече са обхванати от други индекси.
-
Широки клавиши, тъй като клъстерираният индекс се използва и при търсене на неклъстерни индекси.
-
GUID колони, които са по-големи от идентичности и също така ефективно произволни стойности (малко вероятно да бъдат сортирани по), въпреки че
newsequentialid()може да се използва за смекчаване на физическото пренареждане по време на вмъкване. -
Рядка причина за използване на купчина (таблица без клъстериран индекс) е, ако данните винаги се осъществяват чрез неклъстерирани индекси и е известно, че RID (вътрешен идентификатор на реда на SQL Server) е по-малък от ключ за клъстериран индекс.
Поради тези и други съображения, като например конкретното ви натоварване на приложението, трябва внимателно да изберете вашите клъстерирани индекси, за да получите максимална полза за вашите заявки.
Също така имайте предвид, че когато създадете първичен ключ в таблица в SQL Server, той по подразбиране ще създаде уникален клъстериран индекс (ако вече няма такъв). Това означава, че ако намерите таблица, която няма клъстериран индекс, но има първичен ключ (както всички таблици трябва), разработчикът преди това е взел решението да я създаде по този начин. Може да искате да имате убедителна причина да промените това (които има много, както видяхме). Добавянето, промяната или отпадането на клъстерирания индекс изисква пренаписване на цялата таблица и всички неклъстерирани индекси, така че това може да отнеме известно време на голяма таблица.
