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

Первичный ключ представляет собой логическую структуру базы данных и должен быть уникальным и не равным NULL (что реализуется с помощью индекса).

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

Я бы сделал первичный ключ IDENTITY int и кластер на нем.

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

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

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

Реальная скорость запроса (чтения) для типичных запросов OLTP достигается за счет покрытия запроса максимально узкими некластеризованными индексами для всех таблиц в запросе с каждым столбцом в соответствующем порядке и правильным направлением сортировки для запроса/параметров.

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

Тем не менее, я утверждаю, что у вас немного наоборот. Адрес электронной почты создаст особенно ПЛОХОЙ кластеризованный индекс, потому что он изначально не упорядочен. По мере роста таблицы вы потеряете INSERT производительность из-за разделения страниц, изменения порядка и т. д.

Как сказал @Cade Roux, я бы сделал autonum кластерным индексом, обеспечил уникальность адреса электронной почты.

EDIT: кластеризованный индекс показывает, как данные физически хранятся на диске. Непоследовательные кластеризованные индексы снижают INSERT производительность, поскольку данные необходимо переупорядочивать (что приводит к разбиению страниц). При сканировании отдельных строк в таблице пользователей вы, скорее всего, обнаружите незначительную разницу между кластеризованным и некластеризованным индексом. Однако, согласно отличной ссылке, опубликованной @gbn, вы можете иметь лучшую производительность при выборе диапазона, поскольку данные являются последовательными. Тем не менее лично мне пришлось бы серьезно обдумать решение об использовании строк (или любых изначально неупорядоченных данных) для кластеризованного индекса.

EDIT2: Один исключительный случай, о котором я могу подумать, это если вы обычно выбираете группы пользователей по адресам электронной почты в алфавитном порядке... у вас все еще будут более медленные INSERT, но вы сможете получить эти группы быстрее ... Однако, как сказал @Cade Roux в комментариях: вы не должны ожидать, что однострочные SELECT будут более производительными из-за кластеризованного индекса.

Да, ты можешь. Когда вы создаете таблицу, установите столбцы следующим образом:

CREATE TABLE Members
(
  ID INT NOT NULL IDENTITY(10000,1),
  Email Varchar(200) NOT NULL CONSTRAINT pk_Members PRIMARY KEY NONCLUSTERED,
  Otherstuff ...
)

CREATE CLUSTERED INDEX cdx_Members ON Members(ID)