2 DennisL:
Поиск может быть ускорен по любому полю. Все зависти от оптимизатора. Он может решить вообще использовать table scan (и не всегда зря).
По большому счету Genady прав - Index Tuning Wisard обычно решает проблемы.

PS sql2k. В 7.0 было немного по-другому, по-моему.

Интересная тема.

2 Garya:
Пока я работал с 7.0, я полагал также как и Вы. И для этого были основания, всё подтверждалось практикой. В sql2k я столкнулся с другим поведением. Приведу пример.
sql2k sp2 on NT 4.0 sp6a.
Таблица tmpA - 25492 записи, 38 полей. Поля Id, Cli, Acc имеют тип int.

-- Строим индекс по Id:
create unique clustered index PK_tmpA on tmpA(Id)
GO
-- В качестве текстовых используем эти три выборки:
select *
from tmpA
where Cli = 2667 and Acc = 30

select *
from tmpA
where Cli = 2667

select *
from tmpA
where Acc = 30 and Currency = 1

GO

-- При помощи SET SHOWPLAN_TEXT ON получем, как и ожидалось, использование кластерного индекса во всех трех случаях:
|--Clustered Index Scan(OBJECT[Buh].[dbo].[tmpA].[PK_tmpA]), WHERE[tmpA].[Acc]=Convert([@2]) AND [tmpA].[Cli]=Convert([@1])))

|--Clustered Index Scan(OBJECT[Buh].[dbo].[tmpA].[PK_tmpA]), WHERE[tmpA].[Cli]=Convert([@1])))

|--Clustered Index Scan(OBJECT[Buh].[dbo].[tmpA].[PK_tmpA]), WHERE[tmpA].[Acc]=Convert([@1]) AND [tmpA].[Currency]=Convert([@2])))


-- И, соответствующие результаты, сами записи выборки опущены.

(1 row(s) affected)
Table 'tmpA'. Scan count 1, logical reads 659, physical reads 88, read-ahead reads 356.

(54 row(s) affected)
Table 'tmpA'. Scan count 1, logical reads 659, physical reads 0, read-ahead reads 0.

(1 row(s) affected)
Table 'tmpA'. Scan count 1, logical reads 659, physical reads 0, read-ahead reads 0.




-- создаем составной индекс:
create index IX_tmpA_Cli_Acc on tmpA(Cli asc, Acc desc)
GO
-- Предполагаем использование индекса IX_tmpA_Cli_Acc только в первых двух запросах, однако:

-- При помощи SET SHOWPLAN_TEXT ON во всех трех случаях получем использование индекса:
|--Bookmark Lookup(BOOKMARK[Bmk1000]), OBJECT[Buh].[dbo].[tmpA]))
|--Index Seek(OBJECT[Buh].[dbo].[tmpA].[IX_tmpA_Cli_Acc]), SEEK[tmpA].[Cli]=Convert([@1]) AND [tmpA].[Acc]=Convert([@2])) ORDERED FORWARD)

|--Bookmark Lookup(BOOKMARK[Bmk1000]), OBJECT[Buh].[dbo].[tmpA]))
|--Index Seek(OBJECT[Buh].[dbo].[tmpA].[IX_tmpA_Cli_Acc]), SEEK[tmpA].[Cli]=Convert([@1])) ORDERED FORWARD)

|--Filter(WHERE[tmpA].[Currency]=Convert([@2])))
|--Bookmark Lookup(BOOKMARK[Bmk1000]), OBJECT[Buh].[dbo].[tmpA]))
|--Index Scan(OBJECT[Buh].[dbo].[tmpA].[IX_tmpA_Cli_Acc]), WHERE[tmpA].[Acc]=Convert([@1])))

-- Соответствующие выборки:
(1 row(s) affected)
Table 'tmpA'. Scan count 1, logical reads 5, physical reads 0, read-ahead reads 0.

(54 row(s) affected)
Table 'tmpA'. Scan count 1, logical reads 188, physical reads 0, read-ahead reads 0.

(1 row(s) affected)
Table 'tmpA'. Scan count 1, logical reads 52, physical reads 0, read-ahead reads 0.


Информация, получаемая с помощью SET SHOWPLAN_TEXT ON, показывает использование составного индекса, а уменьшение показателя logical reads, по сравнению с теми же выборками, но в отсутствии составного индекса, говорит об эффективном его использовании во всех трех случаях. Хотя, конечно, выборка с условием where по первому полю работает эффективнее чем по последнему, а их комбинация - лучше всех.

У кого есть возможность, прошу повторить что-либо подобное. Может быть я что-то упустил.

2 qu-qu:
Тут где-то звучал афоризм, не помню чей - не удалось найти, "Читай внимательно и до конца". К этому остается только добавить - "Читай сначала".
Был вопрос:
"индекс по нескольким полям таблицы ... будет ускорять поиск по любому из полей[?]"
Прозвучал ответ:
Индекс по комбинации полей используется если в запросе перечислены первые поля индекса. Если какое-либо поле начиная от первого в запросе пропущено, индекс задействован не будет.
Я попытался показать что может быть использовано любое подходящее поле из составного индекса, в том числе не первое. Зависит это, как Вы правильно заметили, от "селективности". А уж как там этот индекс обрабатывается (scan или seek) - какая разница, если это быстрее чем table scan? Ведь вопрос ( "Читай сначала") звучал именно так: "будет ускорять"? Ответ - будет.

2 KonstN:
Когда я написал "прошу повторить что-либо подобное" я имел в виду не прописные истины из книг "за 21 день", я просил повторить мои выборки на своих таблицах тех, у кого есть компьютер , с установленным sql2k.
Что же касается "покрывающих" индексов, я хорошо о них осведомлен, именно поэтому в моих запросах выбираются все поля. Обратите внимание на символ "*".