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

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