Индекс, клъстериран или неклъстериран, може да се използва от оптимизатора на заявки, ако и само ако най-левият ключ в индекса е филтриран. Така че, ако дефинирате индекс за колони (A, B, C), условие WHERE в [email protected] , на [email protected] или на [email protected] AND [email protected] няма да използва изцяло индекса (виж бележка). Това важи и за условията за присъединяване. Всеки филтър WHERE, който включва A ще разгледа индекса:[email protected] или [email protected] AND [email protected] или [email protected] AND [email protected] или [email protected] AND [email protected] AND [email protected] .
Така че във вашия пример, ако направите клъстерния индекс на part_no като най-левия ключ, след това заявка, търсеща конкретен part_id ще не използвайте индекса и в part-id трябва да съществува отделен неклъстериран индекс .
Сега относно въпроса кой от многото индекси трябва да бъде клъстериран един. Ако имате няколко модела на заявки, които са с еднаква важност и честота и си противоречат по отношение на необходимите ключове (напр. чести заявки от и от двете part_no или part_id ) тогава вземете под внимание други фактори:
- ширина :клъстерираният индексен ключ се използва като ключ за търсене от всички други неклъстерирани индекси. Така че, ако изберете широк ключ (да речем две колони с униидентификатор), тогава правите всички останали индекси по-широки, като по този начин консумирате повече място, генерирате повече IO и забавяте всичко. Така че между еднакво добри ключове от гледна точка на четене, изберете най-тесния като клъстер и направете по-широките негрупирани.
- спорване :ако имате специфични модели на вмъкване и изтриване, опитайте да ги разделите физически, така че да се появят в различни части на клъстерирания индекс. напр. ако таблицата действа като опашка с всички вмъквания в единия логически край и всички изтривания в другия логически край, опитайте се да оформите клъстерирания индекс така, че физическият ред да съответства на този логически ред (напр. ред на опашката).
- разделяне :ако таблицата е много голяма и планирате да разположите разделяне, тогава ключът за разделяне трябва да бъде клъстерираният индекс. Типичен пример са исторически данни, които се архивират с помощта на схема за разделяне на плъзгащ се прозорец. Въпреки че обектите имат логически първичен ключ като 'entity_id', клъстерният индекс се извършва от колона дата и час, която също се използва за функцията за разделяне.
- стабилност :ключ, който се променя често, е лош кандидат за клъстериран ключ, тъй като всяко актуализиране на стойността на клъстерирания ключ и принудително всички неклъстерирани индекси за актуализиране на ключа за търсене, който съхраняват. Тъй като актуализацията на клъстериран ключ също вероятно ще премести записа на друга страница, това може да причини фрагментация на клъстерирания индекс.
Забележка:не напълно лост, тъй като понякога двигателят ще избере неклъстериран индекс за сканиране вместо клъстерирания индекс просто защото е по-тесен и по този начин има по-малко страници за сканиране. В моя пример, ако имате индекс на (A, B, C) и филтър WHERE на [email protected] и проектите за заявка C , индексът вероятно ще се използва, но не като търсене, а като сканиране, тъй като все още е по-бързо от пълно клъстерно сканиране (по-малко страници).
