Смотри план запросов. Если оптимизатор считает нужным использовать этот индекс, то он нужен.

av1975Не, я не про это спросил :)
Вот если это был бы hash b-tree, то точно нельзя было бы использовать составной индекс при отборе только по первому полю в индексе.

А с compressed b-tree ТЕОРЕТИЧЕСКИ можно?
Это кто это Вам сказал, что ASA не будет по hash b-tree использовать составные индексы, если в запросе на условия перечислены только первые поля, входящие в этот индекс ? Еще раз говорю, смотрите план запросов в ISQL, там сразу все увидите.

Я вроде как в FAQ выкладывал статью по индексам, там все как мне кажется достаточно подробно описано. Если чего то не хватает, всегда можно добавить.

av1975 ASCRUS
Это кто это Вам сказал, что ASA не будет по hash b-tree использовать составные индексы, если в запросе на условия перечислены только первые поля, входящие в этот индекс ?

До сегодняшнего дня я искренне в это верил :)

А при составном индексе хранится значения хешей на каждое поле?
Я считал, что один "хеш" сразу на все поля индекса сразу (типа, как на составную строку).
Естественно хэш на каждое поле. И естественно любой составной индекс в независимости от того, как он физически хранится в БД может быть использован оптимизатором запросов, даже если поля захватывают только часть такого индекса, при условиях, которые я перечислил в своей статье.