Привет Всем!

В руководстве по SQL2000 не рекомендуют строить индекс для больших баз, если индексируемое
поле содержит малое количество уникальных ключей (я примерно так перевел эту фразу). В качестве примера приведено поле, которое содержит пол человека - всего 2 уникальных значения.
С этим все понятно - уж больно явный пример.

А теперь вопрос из реальной жизни. Имеется таблица ~100 миллионов записей и в ней поле Category varchar(5).Количество уникальных значений ~10 (может быть вырастет до 20-30).
В типовых запросах используется группировка по данному полю.
ВОПРОС - строить ли индекс по этому полю или нет ?
И может быть имеется какая-нибудь методика (хотя бы приблизительная) для оценки необходимости
построения индекса ?

Index Tuning Wizard ничего не может посоветовать т.к. индекс уже построен (до меня). Просто он занимает > 1Gb места на диске и в связи с прочитанным руководством возник этот вопрос.
Если индекс не дает эффекта, то зачем зря растрачивать место на диске ?

original text was
"Columns Not to Index

Do not index columns that:
1. You seldom reference in a query
2. Contain FEW UNIQUE VALUES.For example, an index on a column with two values, male and female, returns a high percentage of rows.
....."

Я смотрю обсуждение имеет больше теоритический характер, а мне хотелось бы практических советов. Поэтому дам более развернутую версию вопроса

1. Данные.
База предназначена для статистических отчетов и поисков. Обновляется 1 раз в месяц большим куском (8-9 млн записей)
Две основные таблицы
- calls 102 млн записей, рост 8-9 млн в месяц
id int identity - номер записи
start datetime - начало звонка
duration int - продолжительность
client char(7) - код клиента ~110 000 уник.значения, рост 5-6 тыс в месяц
telnumber varchar(10) - тел.номер клиента ~200000 уник.значения, рост 7-8 тыс в месяц
dialled varchar(1 - набранный номер ??? уник.значения,рост ???
destination varchar(5) - код направления, 12 уник.значений
category varchar(5) - категория звонка
class varchar(5) - класс звонка
break varchar(5) - период звонка 3 уник.значения, рост пока не предвидется
inv_number char(10) - номер счета FK_invoices

-invoices 1200 тыс.записей, рост 110-120тыс. в месяц
inv_number char(10) - номер счета
client varchar(7) - код клиента
telnumber char(10) - тел.номер клиента
inv_period datetime - отчетный период
at_code varchar(5) - пакет услуг

2. Типовые запросы
-Всегда присутствует период, но это может пониматься как calls.start так и invoices.inv_period
Далее могут быть заданы/не заданы client, telnumber, dialled, destination, category, break, at_code как со всеми возможными вариантами группировок, так и без них

3.Мои соображения
Пока они заканчиваются тем, что необходим кластерный индекс по calls.start(+ может быть еще что-то). В остальном пока мешанина из руководств и мнений.

4.Чего жду
Какой-то план действий по выявлению оптимальных индексов, учитывая, что база уже активно используется и сносить/создавать индексы да еще на таком объеме хотелось бы ну если не с первого захода, то хотя бы с 3-го

Naschet ispolzovanija Index Tuning Wizard mne ponjatno.
Vopros v sledujushem - chto litshe ili pravilnee
- zapuskat zaprosy po ocheredi v Query Analyzer i srazu po ego okonchanii ITW
- ili skazem cherez Profiler sozdat trace file, zapustit vse zaprosy i natravit potom ITW na trace file
(togda kakie sobytija otslezivat v Profiler-e ?)

I eshe voprosy
Udaljat-li dlja chistoty eksperimenta vse sushestvujushie indeksy ?
I esli udaljat, to ne povlijaet-li posle etogo na resultaty ITW uporjadochivanie tablitsy iz-za predydushego
klasternogo indeksa calls.start ?
Ne pridetsja li mne prodelyvat vse eti operatsii zanovo posle dobavlenija ocherednoi portsii dannyh (smotri opisanie vyshe) ?