Разработка некластеризованных индексов SQL Server

Этот вопрос касается разработки некластеризованных индексов в SQL Server 2005.

У меня есть большая таблица с несколькими миллионами строк. Строки только когда-либо читаются или вставляются. Большинство операций считываются. Я изучал различные запросы SELECT , которые обращаются к таблице с целью повышения скорости доступа для чтения. Дисковое пространство на самом деле не проблема. (Каждая строка имеет уникальный идентификатор, и я использую его в качестве единственного поля в кластеризованном индексе.)

Мой вопрос: если некластеризованный индекс индексирует больше столбцов, чем используется запросом, переводится ли это в более медленное выполнение запроса, чем индекс, который точно соответствует запросу?

По мере увеличения количества отдельных запросов увеличивается и количество перестановок столбцов, используемых в их предложениях WHERE . Я не уверен в компромиссе между наличием большого количества индексов с небольшим количеством столбцов (по одному для каждого запроса) и меньшим количеством индексов для большего количества столбцов.

Например, скажем, у меня есть два запроса SELECT . Первый использует столбцы A, B, C и D в своем предложении WHERE , а второй использует A, B, E и F. Лучше всего было бы определить два индекса, один на A / B / C / D, а другой - на A / B / E / F; или единый индекс на A / B / C / D / E / F?