В транзакционной системе может не быть существенного преимущества для помещения индекса в такой столбец (то есть в столбец ссылок с низкой мощностью), поскольку оптимизатор запросов, вероятно, не будет его использовать. Он также будет генерировать дополнительный дисковый трафик при записи в таблицу, так как индексы должны быть обновлены. Поэтому для FK с низким количеством элементов в транзакционной базе данных обычно лучше не индексировать столбцы. Это особенно относится к системам большого объема.
Обратите внимание, что вам все еще может понадобиться FK для ссылочной целостности и что поиск FK в небольшой справочной таблице, вероятно, не будет генерировать ввод / вывод, поскольку таблица поиска почти всегда будет кэшироваться.
Однако вы можете обнаружить, что по какой-то причине вы хотите включить столбец в составной индекс - возможно, для создания покрывающего индекса для часто используемого запроса.
В таблице, которая часто загружается в больших объемах (например, в хранилище данных), трафик записи индекса будет намного больше, чем трафик загрузки таблицы, если у вас много индексированных столбцов. Вероятно, вам придется удалить или отключить FK и индексы для массовой загрузки, если какие-либо индексы присутствуют.
В Star Schema вы можете получить некоторую выгоду от индексации столбцов с низким числом элементов даже на SQL Server. Если вы выполняете высокоселективный запрос (т. Е. Тот, в котором оптимизатор запросов решает, что возвращаемый набор строк будет небольшим), то он может выполнить план «звездного запроса», в котором используется метод, известный как пересечение индекса.
Как правило, планы запросов в звездообразной схеме должны основываться на сканировании таблицы таблицы фактов или на очень избирательном процессе, который закладывает таблицу фактов и затем возвращает меньший набор строк. Пересечение индексов эффективно для последнего типа запросов, поскольку выбор может быть разрешен до выполнения любых операций ввода-вывода в таблице фактов.
Растровые индексы - это реальная победа для столбцов с низкой кардинальностью на платформах, таких как Oracle, которые их поддерживают, а SQL Server - нет. Несмотря на это, индексы с низким количеством элементов все еще могут участвовать в планах звездных запросов на SQL Server.