Индекс против уникального ключа в SQL Server 2008

Question

У меня есть следующая таблица, которая служит для объединения трех таблиц:

ClientID int
BlogID  int
MentionID   int

Предполагая, что запросы всегда будут поступать через ClientID, я могу создать 1 многостолбцовый индекс (ClientID, BlogID, MentionID).

Вопрос в том, должен ли я создать его как кластерный индекс или уникальный ключ? Я понимаю, что кластерный индекс хранит данные на своих конечных узлах. Конечно, в этом случае индекс равен данным, поэтому я не знаю, будет ли SQL Server дублировать данные или нет. Как бы то ни было, я не могу найти в MSDN ничего о значении использования «уникального ключа».

Чем это отличается от Type = Index & IsUnique = yes?

Может ли кто-нибудь рассказать мне о преимуществах каждого из них?

Answer 1

Кластерный индекс - это «сама таблица», то есть узлы индекса расположены в дереве, а его конечные узлы содержат данные строк. Кластерный индекс не должен быть объявлен как уникальный (хотя обычно это так); если он не уникален, сервер неявно добавляет «uniqalizer» к этому индексу, чтобы каждая строка была уникально идентифицирована.

Другие индексы хранят значение кластеризованного индекса как свои конечные узлы (и, возможно, некоторые другие столбцы, если они включены в предложение INCLUDE в состоянии CREATE INDEX).

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

Answer 2

Кажется, вы спрашиваете разницу между:

 MYTABLE
 id integer primary key autoincrement
 clientid integer
 blogid integer
 mentionid integer
 -- with a unique composite index on (clientid, blogid, mentionid) and three foreign key constraints

и

 MYTABLE
 clientid 
 blogid
 mentionid
 -- with a composite primary key on (clientid, blogid, mentionid) and three foreign key constraints

и

 MYTABLE
 id integer primary key autoincrement
  clientid integer
  blogid integer
  mentionid integer
  with an index on clientid and also an index on blogid and the three foreign key constraints

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

Прирост производительности при незначительно большей эффективности второго варианта будет минимальный , и поэтому я буду основывать решение на других факторах. Третий является наиболее гибким с точки зрения запросов и предлагает большую простоту кодирования; он предлагает преимущества индексов на клиенте и блоге, если вы хотите получить запрос с блогом, а не с клиентом, в предложении WHERE. Что касается кодирования, некоторые инструменты с графическим интерфейсом и промежуточное программное обеспечение имеют проблемы с первичными ключами, состоящими из нескольких частей, и ваша логика обновления / вставки / удаления будет проще, если она будет иметь дело с одним целочисленным столбцом PK. Я обнаружил, что простота кода и простота обслуживания гораздо лучше, чем несколько секунд или всего несколько долей секунды улучшения времени ответа на запрос.

Answer 3

UNIQUE INDEX и UNIQUE CONSTRAINT - несколько разные понятия.

• UNIQUE CONSTRAINT является логическим понятием и означает «убедитесь, что этот столбец уникален, независимо от того, как»
• UNIQUE INDEX является физическим понятием и означает «создать индекс B-Tree для этого столбца и завершаться ошибкой при вставке туда дубликатов»

Последнее подразумевает первое, но не наоборот.

Например, в Oracle, если у вас есть неуникальный индекс в col1:

• CREATE UNIQUE INDEX (col1) потерпит неудачу и скажет "эти столбцы уже проиндексированы"
• ALTER TABLE ADD CONSTRAINT UNIQUE(col1) будет успешным и будет использовать существующий индекс для контроля ограничения.

Используйте CONSTRAINT, если вы хотите, чтобы столбец был уникальным, и INDEX, если вы знаете, что индекс B-Tree - это то, что вам нужно (для ускорения поиска и т. Д.).

Answer 4

Данные будут не дублироваться, если вы создадите кластерный уникальный индекс для трех столбцов.

Уникальный кластеризованный индекс будет быть данными - и индексом одновременно :-)

Поскольку это таблица трехстороннего соединения, этот кластерный индекс, вероятно, имеет большой смысл. Я бы сказал: дерзай!

Answer 5

• A unique index, unique key и unique constraint в основном тоже самое. Они приводят к Индекс, обеспечивающий уникальность.

• Clustered означает, что индекс становится самой таблицей. Хорошо иметь кластерный индекс, в противном случае стол висит в неупорядоченная куча.

Уникальные и кластерные несвязанные свойства. Вы можете комбинировать их так, как вам нравится. Так что в вашем случае я бы создал уникальный кластерный индекс. Обычный способ сделать это - создать индекс как clustered primary key.