Съгласен съм с Cade Roux.
Тази статия трябва да ви насочи към правилния път:
- Индекси в SQL Server 2005/2008 – Най-добри практики, част 1
- Индекси в SQL Server 2005/2008 – Част 2 – Вътрешни елементи
Едно нещо, което трябва да се отбележи, клъстерираните индекси трябва да имат уникален ключ (колона за идентичност, която бих препоръчал) като първа колона. По принцип това помага на вашите данни да се вмъкнат в края на индекса и да не причинява много дисково IO и разделяне на страници.
Второ, ако създавате други индекси за вашите данни и те са изградени умно, те ще бъдат използвани повторно.
напр. представете си, че търсите таблица в три колони
щат, окръг, пощенски код.
- понякога търсите само по състояние.
- понякога търсите по щат и окръг.
- често търсите по щат, окръг, пощенски код.
След това индекс с щат, окръг, пощенски код. ще се използва и при трите търсения.
Ако търсите доста само чрез zip, горният индекс няма да се използва (все пак от SQL Server), тъй като zip е третата част от този индекс и оптимизаторът на заявки няма да види този индекс като полезен.
След това можете да създадете индекс само в Zip, който ще се използва в този случай.
Между другото, можем да се възползваме от факта, че с индексиране с няколко колони първата колона на индекса винаги е използваема за търсене и когато търсите само по „state“, тя е ефективна, но все пак не толкова ефективна, колкото индекса с една колона за „state“ '
Предполагам, че отговорът, който търсите, е, че зависи от вашите клаузи къде на често използваните ви заявки, както и от групата ви от.
Статията ще помогне много. :-)
