Alexander_KM,

Тут достаточно много может быть вводных: какой индекс? какая нагрузка преобладает? какой конечной цели вы хотите добиться?

Уже не помню точно у кого когда то читал то ли Бен Ган толи Рендал рекомендовал почти всегда иметь на таблицах кластерный индекс, но это обуславливалось сравнением куч и кластерного индекса.

Лично для себя я выработал позицию что индекс нужно строить исходя из факта выгоды его использования, если более точно - специфики запросов оперирующих к таблице.

нет никакого профита что на табличке
вы построите такой индекс а запросы идут


в надежде на то что когда то вам понадобится быстрая выборка по колонке key

поэтому вопрос топика уж очень абстрактный

Alexander_KM,
если коротко, ответ на ваш вопрос должен выглядеть так:
видите явно узкие места в запросах/планах стройте индекс, не видите пусть работает.

Если Вы вдруг проектируете сферического коня в вакууме какую то систему в потенциалом что в будущем объемы данных вырастут и вам понадобятся индексы на таблицах, продумайте просто заранее в каких местах будет выигрыш от их использования в зависимости от конкретных запросов.
Понятное дело что не возможно заранее продумать все возможные варианты, но проблемы можно будет решать по мере их поступления.

Alexander_KM,

что бы не быть голословным вот неплохая статья на тему сравнения куч и кластерных индексов
https://www.sqlshack.com/clustered-index-vs-heap/

а вот размышления Рендала по поводу наличия индексов на таблицах
https://www.sqlskills.com/blogs/paul/over-and-under-indexing-how-bad-is-it-out-there/