Есть ли какое-либо преимущество в создании кластеризованного индекса, если мы не собираемся запрашивать/искать записи на основе этого столбца?

Я бы сказал, что ваша таблица неправильно спроектирована. Кто-то, видимо, думал, что каждой таблице нужен первичный ключ, а первичным ключом является кластеризованный индекс. Добавление сгенерированного системой уникального номера в качестве идентификатора просто добавляет шума, если этот номер нигде не используется. Шум в кластеризованном индексе, мягко говоря, бесполезен.

Между прочим, это разные понятия. Первичный ключ — это проблема моделирования данных, логическая концепция. Индекс - это проблема физического дизайна. СУБД SQL должна поддерживать первичные ключи, но не должна иметь индексов, кластеризованных или отсутствующих.

Если USERID — это то, что обычно используется для поиска в таблице, оно должно быть в вашем кластеризованном индексе. Кластеризованный индекс не обязательно должен быть уникальным и не обязательно должен быть первичным ключом. Я бы внимательно посмотрел на данные, чтобы увидеть, образует ли какая-то комбинация USERID и другого столбца (или двух, или более) уникальный идентификатор строки. Если это так, я бы сделал это первичным ключом (и кластеризованным индексом) с USERID в качестве первого столбца. Если бы анализ запросов показал, что многие запросы используют только USERID и ничего больше (для проверки существования), я мог бы создать отдельный индекс только для USERID.

Если никакая комбинация столбцов не представляет собой уникальный идентификатор, у вас есть логическая проблема, а именно: что означает строка? Какой аспект реального мира он представляет?

Основной принцип реляционной модели заключается в том, что элементы в отношении (строки в таблице) уникальны, и каждый из них идентифицирует что-то. Если две строки идентичны, они обозначают одно и то же. Что значит удалить один из них? То, что они оба идентифицируют, все еще там или нет? Если да, то какой цели служил второй ряд?

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

Если столбец IDENTITY никогда не используется в предложениях WHERE и JOIN или на него ссылаются внешние ключи, возможно, USERID должен быть кластеризованным первичным ключом. В этом случае я бы вообще поставил под сомнение необходимость столбца ID.

Лучший выбор для кластерного индекса во многом зависит от того, как запрашивается таблица. Если большинство запросов выполняется по USERID, то, вероятно, это должен быть уникальный кластеризованный индекс (или кластеризованное уникальное ограничение) и некластеризованный столбец ID.

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