Кластеризованные индексы должны быть уникальными?

Что произойдет, если кластерный индекс не уникален? Может ли это привести к плохой производительности, потому что вставленные строки перетекают на страницу переполнения?

Разве это "сделано" уникальным, и если да, то как? Каков наилучший способ сделать его уникальным?

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

Спасибо!

Ответ 1

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

Что произойдет, если вы создадите CI в уникальном столбце

Если кластеризованный индекс не является уникальным index, SQL Server делает любой дубликат уникальные ключи, добавляя внутренне генерируемое значение, называемое уникальным идентификатором

Это приводит к плохой производительности?

Добавление уникального идентификатора, безусловно, добавляет некоторые накладные расходы при вычислении и хранении.
Если эти служебные данные будут заметны, это зависит от нескольких факторов.

Сколько данных содержится в таблице.
Какова скорость вставки.
Как часто используется CI в select (когда нет индексов покрытия, почти всегда).

Edit
как было отмечено Ремусом в комментариях, существуют варианты использования, когда создание неидеального CI было бы разумным выбором. Я, не столкнувшись с одним из этих сценариев, просто демонстрирует свою собственную недостаточную подверженность или компетентность (выберите ваш выбор).

Ответ 2

Мне нравится проверять, что Королева Индексации, Кимберли Трипп, должна сказать по теме:

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

Начнем с ключевых вещей, которые я ищу в кластерном ключе:

* Unique
* Narrow
* Static

Почему уникальный? Клавиша кластеризации должна быть уникальной, поскольку ключ кластеризации (когда он существует) используется как ключ поиска из всех некластеризованных индексов. Возьмем, например, индекс в задней части книги - если вам нужно найти данные, на которые указывает указатель, - эта запись (запись индекса) должна быть уникальной в противном случае, какая запись индекса будет той, которую вы ищете? Таким образом, при создании кластерного индекса он должен быть уникальным. Но SQL Server не требует, чтобы ваш ключ кластеризации был создан в уникальном столбце. Вы можете создать его на любом столбце (столбцах), который вы хотите. Внутри, если ключ кластеризации не является уникальным, SQL Server будет "uniquify" его, добавив 4-байтовое целое к данным. Поэтому, если кластеризованный индекс создается на некотором уникальном объекте, то не только возникают дополнительные накладные расходы при создании индекса, затрачивается дисковое пространство, дополнительные затраты на INSERT и UPDATE, а в SQL Server 2000 добавляются дополнительные затраты на индекс clustereD rebuild (что из-за плохого выбора для ключа кластеризации теперь более вероятно).

Источник: Постоянная дискуссия о кластеризации - снова!

Ответ 3

Нужны ли уникальные кластерные индексы?

Они не делают, и есть моменты, когда это лучше, если они не являются.

Рассмотрим таблицу с полуслучайным уникальным EmployeeId и DepartmentId для каждого сотрудника: если ваш оператор select

SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%

тогда это лучше всего для производительности, если DepartmentId является кластеризованным индексом, хотя (или даже тем более), что он не является уникальным индексом (лучше всего подходит для производительности, потому что он гарантирует, что все записи в пределах данного отделаId кластеризованы).

Есть ли у вас какие-либо ссылки?

Здесь Руководство по разработке кластерных указателей, в котором говорится,

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

Может использоваться для часто используемых запросов.

Обеспечьте высокую степень уникальности.

Может использоваться в запросах диапазона.

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