ТУПО: для PK - кластерный, для всего остального — нет.
СОВСЕМ ТУПО: не знаешь, какой индекс делать кластерным — делай все некластерными.
ПО-УМНОМУ: если надо делать большие range scan -ы по индексу — делай его кластерным. Но повезёт только один раз...

Кластерный перед некластерным вообще имеет очень маленький выигрышь, хотя и имеет конечно,
но у него есть один существенный недостаток (у кластерного) - он в таблице может быть ТОЛЬКО ОДИН.

Хорошо, а если представим ситуацию такую

Вот есть у нас мессенджер, есть какая-то таблица сообщений с 10 миллионами записей
Мы зафигачили кластер-индекс по диалогу например

К примеру у нас есть диалог с миллионом записей - то есть какая-то выборка по нему будет все равно не очень быстрая
И мне например надо там еще выбирать по каким-то свойствам сообщения с этого диалога (по каким сложно придумать, но пусть этих свойств еще будет 3)
Стоит ли строить некластерный индекс по этим полям в такой ситуации?

А сейчас уже почти всё равно... очень расхожая схема сейчас у многих СУБД — кластерный PK

Стоит ли строить (некластерный) индекс по этим полям в такой ситуации? — это вообще другой, совершенно отдельный вопрос.
НИКАК не связанный с предыдущим вопросом.

Судя по всему, тебе подойдёт, на твоём уровне понимания, пункт "ТУПО" , тем более, что SQLServer

Там в диалогах текст

Идексы текста работают по другому

Наверняка этот индекс будет отдельным столбцом в таблице
Или типа того

Вроде

И вот ровно с таким подходом (на уровне коленного рефлекса) я и видел ситуации (суть которых описана по ссылке), когда "умница"-консультант или DBA, глядя на heap-таблицу с десятком индексов, говорил "ну что же вы, это же плохая практика! Срочно переделать!"... и  после внедрения "улучшения" производительность падала в разы. ;)

Так что лучше думать, если ситуация такая, когда это может иметь значение, вот в чём был мой посыл.

я имею ввиду не по тексту выборку делаем, а по каким-то абстрактным свойствам
ну, например, какое сообщение не прочитано и так далее, это вообще не важно

сложно придумать просто свойства сообщений)

Так это был наверное консультант по SQLServer...

Ярослав, там же был и пункт "СОВСЕМ ТУПО"

Да.
А где ещё "основное" название index-organized table сейчас "кластерный индекс", кстати?

Сложно говорить о индексах абстрактно...

Везде, кроме оракла и PG... AFAIK

Хорошо, ок
Пусть будет делаем выборку в этом диалоге (это будет груповой чат) сообщений, которые были прочитаны и которые написали женщины допустим

Так лучше ?

Я каждый запрос из моих сервисов к бд проверяю руками

Смотрю где индексы настроены, а где нужно настроить

И да, это ведет к большему количеству индексов чем вроде как нужно

Но я ж могу добавить всегда шард на запись

А если все совсем плохо станет, то позвать консультанта :)

Нет, хуже. Индекс не нужен для этих условий.

Я понимаю что не нужен так как это булевые значения

Я утрировано

Да, похоже на то, спасибо!
Всё-таки не очень удачное название (по самому названию непонятно, что это такое... а некоторые и вовсе понимают иначе), IMHO.