2017-01-05 6 views
2

Учитывая таблицу базы данных:Необходимо создать индекс для первичного ключа многополюсного сервера SQL Server?

UserID (PK) 
SomeTypeID (PK) 
SomeSubTypeID (PK) 
Data 

И вы хотите запросить:

SELECT Data FROM Table WHERE UserID = {0} AND SomeTypeID = {1} AND SomeSubTypeID = {2} 

вам нужно будет создать индекс UserID, SomeTypeID, SomeSubTypeID или же тот факт, что они образуют первичный ключ означает, что это не нужно?

+2

Первичный ключ уже создает индекс сортировки. Если вы не хотите запрашивать другие столбцы, изолированные друг от друга, должно быть хорошо использовать только первичный ключ. Подробнее: https://msdn.microsoft.com/en-us/library/ms189039.aspx (при условии, что вы используете Microsoft SQL) –

+0

Возможный дубликат ... http://stackoverflow.com/questions/462477/sql-primary -key-и-индекс? RQ = 1 –

ответ

3

Если вы создали первичный ключ, как:

CREATE TABLE TBL (UserID, SomeTypeID, SomeSubType, Data 
    CONSTRAINT PK PRIMARY KEY (UserID, SomeTypeID, SomeSubType)) 

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

Обычно (так не всегда), при поиске данных, которые вы хотели бы ваши запросы использовать NON-CLUSTERED индекс для фильтрации строк, где столбцы, которые вы используете для фильтрации строк будут формировать ключ индекса и информация (колонка), что вы вернетесь из этих строк как INCLUDED столбца, в данном случае DATA, как показано ниже:

CREATE NONCLUSTERED INDEX ncl_indx 
ON TBL (UserID, SomeTypeID, SomeSubType) INCLUDE (Data); 

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

Но, вы можете указать тип индекса, который вы хотите, чтобы ваш PRIMARY KEY быть, так:

CREATE TABLE TBL (UserID, SomeTypeID, SomeSubType, Data 
    CONSTRAINT PK PRIMARY KEY NONCLUSTERED (UserID, SomeTypeID, SomeSubType)); 

Buuut, потому что вы хотите, чтобы он был определен как PRIMARY KEY то вы не в состоянии использовать функциональность INCLUDE, поэтому вы не можете избежать поиска диска, чтобы получить информацию из столбца DATA, где вы в основном используете индекс по умолчанию CLUSTERED.

Buuuuuut, есть еще способ гарантировать уникальность, что первичный ключ дает вам и выгоду от INCLUDE функциональности, чтобы сделать, как меньшее количество дисковых операций ввода Выходов /.

Вы можете указать NONCLUSTERED INDEX как UNIQUE, который гарантирует, что все ваши 3 столбца, составляющие индексный ключ, уникальны.

CREATE UNIQUE NONCLUSTERED INDEX ncl_indx 
ON TBL (UserID, SomeTypeID, SomeSubType) INCLUDE (Data); 

Делая все это, то ваша таблица будет HEAP, which is not a very good thing. Если вы хорошо подумали о разработке своих таблиц и решили, что лучший кластеризованный ключ для вашего CLUSTERED INDEX (UserID, SomeTypeID, SomeSubType), тогда лучше оставить все, как у вас в настоящее время.

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

1

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

Подумайте о создании отдельного индекса, если вы планируете фильтровать один из столбцов, а не другие. Например: SELECT данные из таблицы WHERE UserID = {0}

 Смежные вопросы

  • Нет связанных вопросов^_^