первичный ключ sql и индекс

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

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

, Например, у Вас есть таблица со многими столбцами, но Вы только запрашиваете идентификатор, столбцы Name and Address. Беря идентификатор в качестве первичного ключа, мы можем создать следующий индекс, который основан на идентификаторе, но включает столбцы Name and Address.

CREATE NONCLUSTERED INDEX MyIndex
ON MyTable(ID)
INCLUDE (Name, Address)

Так, когда Вы используете этот запрос:

SELECT ID, Name, Address FROM MyTable WHERE ID > 1000

SQL Server даст Вам результат только с помощью индекса, который Вы создали, и это ничего не считает из фактической таблицы.

ПРИМЕЧАНИЕ: Этот ответ обращается к разработке промышленного класса в-большом .

Это - проблема RDBMS, не только SQL Server, и поведение может быть очень интересным. Для одного, в то время как первичным ключам свойственно быть автоматически (исключительно) индексированным, это не абсолютно. существуют времена, когда важно, чтобы первичный ключ НЕ был исключительно индексирован.

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

Теперь для забавной части - когда Вы НЕ хотите уникального индекса первичного ключа? Вы не хотите один и не можете терпеть один, когда Ваша таблица получает достаточно данных (строки) для создания обслуживания индекса слишком дорогим. Это варьируется на основе аппаратных средств, механизма RDBMS, характеристик таблицы и базы данных и системной нагрузки. Однако это обычно начинает проявлять, как только таблица достигает нескольких миллионов строк.

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

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

Первичные ключи всегда индексируются по умолчанию.

можно определить первичный ключ в SQL Server 2012 при помощи Studio управления SQL Server или Transact-SQL. Создание первичного ключа автоматически создает соответствующий уникальный, кластеризованный или некластеризованный индекс.

http://technet.microsoft.com/en-us/library/ms189039.aspx

PK станет кластерным индексом, если Вы не определите не кластеризируемый

Здесь проход из MSDN:

при определении ограничения PRIMARY KEY для таблицы Механизм базы данных осуществляет уникальность данных путем создания уникального индекса для столбцов первичного ключа. Этот индекс также разрешает быстрый доступ к данным, когда первичный ключ используется в запросах. Поэтому первичные ключи, которые выбраны, должны следовать правилам для создания уникальных индексов.

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

У меня есть огромная база данных без (отдельного) индекса.

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

первичные ключи автоматически индексируются

, можно создать дополнительные индексы с помощью pk в зависимости от использования

• индекс zip_code, идентификатор может быть полезным, если Вы часто выбираете zip_code и идентификатором