Строить индекс или нет

Glory
Дата: 21.02.2001 10:41:40
Привет Всем!

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

А теперь вопрос из реальной жизни. Имеется таблица ~100 миллионов записей и в ней поле Category varchar(5).Количество уникальных значений ~10 (может быть вырастет до 20-30).
В типовых запросах используется группировка по данному полю.
ВОПРОС - строить ли индекс по этому полю или нет ?
И может быть имеется какая-нибудь методика (хотя бы приблизительная) для оценки необходимости
построения индекса ?
Александр Гладченко
Дата: 21.02.2001 10:54:23
А Index Tuning Wizard что Вам советует?
Glory
Дата: 21.02.2001 11:30:11
Index Tuning Wizard ничего не может посоветовать т.к. индекс уже построен (до меня). Просто он занимает > 1Gb места на диске и в связи с прочитанным руководством возник этот вопрос.
Если индекс не дает эффекта, то зачем зря растрачивать место на диске ?
Genady
Дата: 21.02.2001 12:47:40
Судя по всему фраза переведена неправильно, как я понимаю в ней имеется в виду, что не стоит строить индекс на полях с низкой селективностью, т. е. если запросы чаще всего возвращают большое количество записей и оптимизатор вычисляет, что дешевле выборку делать не по индексу а просто сканировать таблицу. Используется ли индекс, можно посмотреть в Query Analyzer включив показ плана выполнения запроса.
А вот Index Tuning Wizard всегда может че нить полезное посоветовать, даже если и индекс уже построен.
Александр Гладченко
Дата: 21.02.2001 12:50:04
Присоеденяюсь к Genady, он меня опередил на секунду...
Genady
Дата: 21.02.2001 12:53:45
Да вот еще посмотрел на число уникальных значений (не ключей - разные вещи совершенно), то скорее всего индекс здесь действительно не нужен, но я бы все равно попроверял все зависит от запросов. Можно было бы попробовать кластерный, но при этом есть опасность и достаточно большая что операции insert, update будут выполняться невообразимо медленно.
Glory
Дата: 21.02.2001 13:20:30
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.
....."
Genady
Дата: 21.02.2001 13:57:49
Ну, так все верно Values - значений, Unique key это Primary key or Alter key.
Индекс Вам скорее всего не нужен.
Самая простая методика как я уже говорил, посмотреть по плану выполнения запроса используется ли он в типовых запросах. Если нет, то однозначно не нужен, он ничего не дает, ну а наоборот ессно нужен. )
Как я говорил ранее, нужно посмотреть тип индекса, если он некластерный и обновления происходят очень редко, то я думаю (не уверен, но попробовать можно) можно попробовать сделать этот индекс кластерным. В таком случае записи в таблице сортируются и скан будет производится проще и быстрее. Однако, если обновления часты и таблица, как я понял большая, то этот индекс просто убьет быстродействие по операциям insert and update.
Удачи )
VadimB
Дата: 21.02.2001 17:38:21
Индекс из 30 разных значений на 100 миллионов можжно смело удалить.
А уж делать его кластерным ... просто нет слов.
Genady
Дата: 22.02.2001 10:11:24
>А уж делать его кластерным ... просто нет слов.

Вобще то, было бы лучше, ели бы слова все таки нашлись, потому что откровенно говоря я не понимаю как Full table scan может быть быстрее clustered index scan. На всякий случай я еще раз повторюсь, что я говорю именно о select-ах.

Да, вот небольшая цитата из Books online:

Before creating clustered indexes, understand how your data will be accessed. Consider using a clustered index for:

Columns that contain a limited number of distinct values, such as a state column that contains only 50 distinct state codes. However, if there are very few distinct values, such as only 1 and 0, no index should be created.