Доброго времени суток!
есть таблица, в которой есть поле Status Char(1)
смысл этого поля это хранить состояние текущей записи, т.е. определнный символ в поле для каждой записи имеет смысл, типа
А - запись активна
Н - запись в архиве
W - запись обрабатывается
и т.д.
естественно основная масса записей в таблице имеет статус=Н
записей с остальным статусом не более 100 в день
в таблице записей не так и много около 50000.
построил по этому полю индекс
create index MainList_IDX1 on MainList (STATUS);

запрос:
select t.* from MainList t Where (t.status='W' or t.Status='F')
выдает 6 записей.
посмотрел через анализатор запросов, этот запрос, оказалось что происходит 164 чтения с использованием индекса

анализатор IBAnalist ругается на этот индекс говорит что слишком много одинаковых.

Подскажите, плииз, почему при использовании индекса по этому полю, происходит аж 164 чтения, когда записей этому запросу соответствующих всего 6. И почему этот индекс считается плохим? и какой тогда будет лучше?
например если сделать индекс по уникальному полю + статус, тогда все записи будут уникальны, но если я делаю условие в выборке по полую статус и ни как не использую в нем уникальное поле ключа, то  так думаю такой индекс вообще не будет использоваться ...

Потому и плохой, что всего мало разных значений. Смысл читать сначала индекс, а потом по нему данные практически пропадает. Проще по данным пробежаться.

> например если сделать индекс по уникальному полю + статус,
> тогда все записи будут уникальны, но если я делаю условие
> в выборке по полую статус и ни как не использую в нем уникальное
> поле ключа, то  так думаю такой индекс вообще не будет использоваться

А вот если сделать статус+уникальное поле, то вполне верятно (хотя не факт) и смысл появится. Не на этом запросе, так на другом.
Вообще создание индексов это штука интересная. Одним индексом можно систему положить на лопатки и заставить летать.
Создание "настроечных" индексов лучше отложить на потом, когда система будет готова и можно будет анализировать основные запросы пользователей.

> А вот если сделать статус+уникальное поле, то вполне верятно
> (хотя не факт) и смысл появится.

сделал такой индекс (STATUS,ID)
действительно анализатор показал что происходит всего 6 индексных чтений

но если сделать индекс (ID,STATUS) результат тот же  - 6 чтений

т.е порядок полей при создании индекса не влияет на его работу?

но если сделать два индекса
(STAUS,ID) и (ID,STATUS)
то анализатор показывает что в запросе используется первый индекс

> [2] ford ©   (02.07.10 11:38)

Попробуй запрос с
Where (t.status='W' or t.Status='F') and ID>10000
Where ID<500 and (t.status='W' or t.Status='F')
или нечто похожее для разных индексов.

Вроде как должны быть отличия. Хотя утверждать не буду. Оптимизаторы у всех разные.

> Попробуй запрос с
> Where (t.status='W' or t.Status='F') and ID>10000
> Where ID<500 and (t.status='W' or t.Status='F')
> или нечто похожее для разных индексов.


попроболвал... тоже самое
для всех используется один индекс (STATUS,ID) собственно который определн был первым, если его деактивировать, то тогда используется (ID,STATUS)

> ford  (02.07.2010 10:16:00)  [0]

Потому что "слишком много одинаковых"

> Sergey13 ©   (02.07.10 11:31) [1]

тут вот что интересно: начиная с 1.5, уникальный индекс позволяет null`ы. Как это реализовано, я не понел, да и не слишком морочился искать. Если как в оракуле, null`ы тупо не индексируются, решение можно подсказать, а если  хз как, то хз.

> тут вот что интересно: начиная с 1.5, уникальный индекс
> позволяет null`ы.


null-ы, или таки один null?

запрос:
select t.* from MainList t Where (t.status='W' or t.Status='F')


Здесь уже объяснили, что индекс тем эффективнее, чем больше различных записей.

в твоем случае запрос вида:


отключит использование неэффективного индекса.

> Ega23 ©   (05.07.10 11:44) [8]

много null`ов