Кластерный или покрывающий индекс

Question

Рассмотрим следующую таблицу в SQL Server 2008:

LanguageCode  varchar(10)
Language      nvarchar(50)

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

Если я добавлю первичный кластеризованный ключ в LanguageCode, конечно, я не смогу включить язык в индекс (индекс покрытия). Это означает, что мне придется создать второй индекс для языка или рискнуть иметь дубликаты в нем (плюс принудительно сканировать таблицу, чтобы получить его значение).

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

В этом случае некластеризованный покрывающий индекс (LanguageCode, Language) не только обеспечит уникальность Language, но и позволит избежать сканирования таблицы. Однако не было бы «идеального» кластерного индекса.

Является ли это одним из тех случаев, когда отсутствие кластеризованного индекса на самом деле идеально?

Редактировать на основе отзывов:

Единственный запрос, который я хочу выполнить:

SELECT Language, LanguageCode FROM Languages where Language="EN"

Answer 1

Кластерный индекс по определению охватывает все столбцы.

Если вы создадите PRIMARY KEY CLUSTERED в LanguageCode и UNIQUE INDEX в Language, это позволит вам искать язык как по его коду, так и по имени с помощью одного поиска, и, кроме того, Language уникальный.

Answer 2

1. Нет необходимости включать столбцы в кластеризованный индекс. Поскольку кластеризованный индекс является «данными», все столбцы включаются автоматически.

2. Если вам нужно выполнить поиск по языку и / или обеспечить его уникальность, обязательно создайте дополнительный индекс для него.

Answer 3

Исходя из характера предмета (я предполагаю, что это языки, на которых говорят люди), индексирование для производительности будет неактуальным.Если бы у вас было 100 языков, и каждая строка занимала 120 байтов (псевдо-факторинг в заголовках varchar, нулевые битовые маски и тому подобное), у вас было бы 12 000 байтов данных, которые помещаются на двух страницах по 8 КБ.SQL не потрудится использовать индексы для чего-то такого маленького, он просто отсканирует таблицу целиком (2 страницы) и перехватит ее, что потребует меньше времени, чем это можно легко измерить.конечно, я делаю это все времяНо для производительности, пока вы не нажмете 3 страницы (или это 4), это просто не имеет значения.(Это произойдет, если вы будете отслеживать языки программирования, потому что каждую неделю появляется десяток новых.)