Связь первичного ключа и кластерного индекса

Может ли TABLE иметь первичный ключ без кластерного индекса?

и может ли TABLE иметь кластерный индекс без первичного ключа?

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

Ответ 1

Первичный ключ - это логическая концепция - это уникальный идентификатор строки в таблице. Таким образом, он имеет множество атрибутов - он может быть не нулем, и он должен быть уникальным. Конечно, поскольку вы, вероятно, будете много искать записи по их уникальному идентификатору, было бы неплохо иметь индекс первичного ключа.

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

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

Да, вы можете создать кластеризованный индекс для столбцов, которые не являются первичным ключом.

Ответ 2

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

Кластеризованный индекс хранит все столбцы на уровне листа. Это означает, что кластерный индекс содержит все данные в таблице. Таблица без кластерного индекса называется кучей.

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

Пример, где t1 имеет некластеризованный первичный ключ, а t2 не кластеризуется, а имеет первичный ключ:

create table t1 (id int not null, col1 int);
alter table t1 add constraint PK_T1 primary key nonclustered (id);
create clustered index IX_T1_COL1 on t1 (col1);

create table t2 (id int not null, col1 int);
alter table t2 add constraint PK_T2 primary key nonclustered (id);

Пример в SQL Fiddle.

Ответ 3

Прежде всего, посмотрите Индексированные таблицы и кластерные индексы. На самом деле, я рекомендую прочитать все Использовать сайт Index Luke! с самого начала, пока вы не достигнете темы кластеризации, чтобы действительно понять, что происходит.

Теперь, на ваши вопросы...


Может ли TABLE иметь первичный ключ без кластерного индекса?

Да, используйте ключевое слово NONCLUSTERED при объявлении вашего первичного ключа для создания таблицы с кучей. Например:

CREATE TABLE YOUR_TABLE (
    YOUR_PK int PRIMARY KEY NONCLUSTERED
    -- Other fields...
);

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


и может ли TABLE иметь кластерный индекс без первичного ключа?

В отличие от некоторых других СУБД, MS SQL Server позволит вам иметь индекс кластеризации, отличный от первичного ключа или даже без первичного ключа.

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

CREATE TABLE YOUR_TABLE (
    YOUR_PK int PRIMARY KEY,
    YOUR_CLUSTERED_KEY int NOT NULL UNIQUE CLUSTERED
    -- Other fields...
);

Если вы выберете уникальный код кластеризации (используя CREATE CLUSTERED INDEX ...), MS SQL Server автоматически сделает его уникальным, добавив к нему скрытое поле.

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


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

В MS SQL Server первичный ключ также кластеризуется по умолчанию. Вы можете изменить это значение по умолчанию, как описано выше.

Ответ 4

Ответы, взятые из MSDN с использованием кластеризованных индексов

Может ли TABLE иметь первичный ключ без кластерного индекса? - Да.

Может ли TABLE иметь кластерный индекс без первичного ключа? - Да.

Первичный ключ - это ограничение, которое обеспечивает уникальность значений, так что строка всегда может быть идентифицирована именно этим ключом.

Индекс автоматически присваивается первичному ключу (так как строки часто "ищут" их первичный ключ).

Некластеризованный индекс является логическим упорядочением строк одним (или более) его столбцами. Подумайте об этом как о другой "копии" таблицы, упорядоченной любыми столбцами индекса.

Кластеризованный индекс - это когда фактическая таблица физически упорядочивается определенным столбцом. В таблице не всегда будет кластеризованный индекс (т.е. Пока он будет физически упорядочен чем-то, это может быть undefined). В таблице не может быть более одного кластерного индекса, хотя он может иметь один составной кластеризованный индекс (т.е. Таблица физически упорядочивается, например, фамилия, имя, DOB).

PK часто (но не всегда) кластеризованный индекс.

Ответ 5

Возможно, это не ответ на этот вопрос, но некоторые важные аспекты первичного ключа и кластеризованных индексов →

Если есть первичный ключ (по умолчанию, который является кластеризованным индексом, однако мы можем его изменить) с помощью Clustered Index, то мы не сможем создать еще один кластерный индекс для этой таблицы. Но если еще нет первичного набора ключей, и есть кластеризованный индекс, то мы не сможем создать первичный ключ с Clustered Index.

Ответ 6

Для чего это может быть полезно, в MS SQL Server все столбцы первичного ключа должны быть определены как NOT Null, а создание уникального кластеризованного индекса не требует этого. Однако не уверены в других системах БД.