Зато знаю проблемы, которые возникали у слишком "умных" разработчиков, которые не по делу использоватил кластерные индексы и получали из-за снижение производителности при операциях INSERT и UPDATE. Создавая некластерный индекс, разработчик в отдельных случаях рискует дисковым пространством в БД и незначительным замедлением поиска (по сравнению с кластерным) при извлечении строк из таблицы по этому некластерному индексу.

2 Oleg F
Я не согласен с тем, что некластерный индекс всегда медленне кластерного, в некоторых случаях он работает быстрее когда в запросе перечислены поля (имею ввиду то что перечисленно в Select,Where,group by), которые имеются в некластерном индексе. То в этом случае серверу не приходится читать страницы с данными а использует информацию последних страниц индекса. В результате получается аналог кластерного. Вот на примере у меня была громоздкая таблица, в которой было 50 млн. записей.
(КодСлучая,КодМедуслуги,Стоимость,Количество) медуслуги оказанные пациенту в случае определямом КодСлучая. Когда я собрался оптимизировать запрос у меня был всего один некластерный индекс по полю КодСлучая, ну я решил проверить что же посоветует Index Tuning Wizard и он мне посоветовал создать некластерный по 4 полям, я сперва не понял, но сделал и производидельность резко возросла. Затем когда прочел статью о том как устроены кластреные индексы и некластерные и что в некоторых случаях некластерный индекс работает аналогично кластерному я решил создать кластерный по полю КодСлучая дабы сэкономить 1,5-2 Гига. Место действительно сэкономил, но производительность на выборках упала на 10% . В результате я отказался от кластерного, лучше потратить лишних 2 Гига, и выиграть как в Select так и при Insert.

qu-qu правильно меня понял. Прошу прощения за то что не написал, что некластерный по 4 полям был удален и взамен был создан кластерный по одному полю КодСлучая. Поэтому и вышла экономия места, но производительность упала на 10%.

Не я непробовал. Просто долго создавать такие индексы на таблице в 50 млн. записей. Да и на такой машине с 192 метрами оперативки и с одним IDEшным винтом. Но как мне кажется, может я и ошибаюсь, но процессор запросов даже при наличии двух индексов кластерного по одному полю и некластерного по 4 полям будет использовать в запросе некластерный индекс.
Ведь не просто так Index Tuning Wizard посоветовал для оптимизации сделать именно некластерный по 4 полям, а не кластерный по одному полю.

2 Владимир Смирнов.
Я боюсь что первый раз неправильно вас понял по поводу

Вы не пробовали вариант с обоими индексами одновременно.
Как в отношении объёмов, так и в отношении производительности?

Что вы хотели этим сказать? создать индекс кластерный по 4 полям проверить запрос, а затем некластерный по 4 полям и сравнить оба результата в Как в отношении объёмов, так и в отношении производительности?
Так я не пробовал.