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

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

Это" сделано " уникальным, и если да, то как? Как сделать его уникальным?

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

спасибо!

3 ответов


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

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

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

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

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

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

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


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

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

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

* Unique
* Narrow
* Static

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

источник: постоянно растущая кластеризация ключевых дебатов-снова!


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

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

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

SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%

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


у вас есть какие-нибудь рекомендации?

здесь Рекомендации По Дизайну Кластеризованных Индексов например, в котором говорится:

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

  • может использоваться для часто используемых запросов.
  • обеспечиваем высокую степень уникальности.
  • может использоваться в запросах диапазона.

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