Скажем, у меня есть строка ID (int) в базе данных, заданной как первичный ключ. Если я часто запрашиваю идентификатор, мне также нужно его индексировать? Или это первичный ключ означает, что он уже проиндексирован?
Причина, о которой я прошу, заключается в том, что в MS SQL Server я могу создать индекс для этого идентификатора, который, как я сказал, является моим основным ключом.
Изменить: дополнительный вопрос - будет ли он причинять вред дополнительно индексировать первичный ключ?
Вы правы, это путает, что SQL Server позволяет создавать повторяющиеся индексы в одном и том же поле. Но тот факт, что вы можете создать другое, не указывает на то, что индекс PK также не существует.
Дополнительный индекс не подходит, но единственный вред (очень маленький) - дополнительный размер файла и накладные расходы на создание строк.
Как уже сказали все остальные, первичные ключи автоматически индексируются.
Создание большего количества индексов в столбце первичного ключа имеет смысл только тогда, когда вам нужно оптимизировать запрос, который использует первичный ключ и некоторые другие конкретные столбцы. Создав еще один индекс в столбце первичного ключа и включив в него некоторые другие столбцы, вы можете достичь желаемой оптимизации для запроса.
Например, у вас есть таблица со многими столбцами, но вы только запрашиваете столбцы ID, Name и Address. Принимая идентификатор в качестве первичного ключа, мы можем создать следующий индекс, который построен на ID, но включает столбцы имен и адресов.
CREATE NONCLUSTERED INDEX MyIndex
ON MyTable(ID)
INCLUDE (Name, Address)
Итак, когда вы используете этот запрос:
SELECT ID, Name, Address FROM MyTable WHERE ID > 1000
SQL Server даст вам результат только с использованием созданного вами индекса и не будет читать ничего из фактической таблицы.
ПРИМЕЧАНИЕ. Этот ответ касается разработки корпоративного класса в.
Это проблема РСУБД, а не только SQL Server, и поведение может быть очень интересным. Для одного, хотя для первичных ключей обычно индексируется автоматически (однозначно), он НЕ является абсолютным. Бывают моменты, когда важно, чтобы первичный ключ НЕ был уникально индексирован.
В большинстве РСУБД уникальный индекс будет автоматически создан на первичном ключе, если он еще не существует. Таким образом, вы можете создать свой собственный индекс в столбце первичного ключа, прежде чем объявлять его как первичный ключ, тогда этот индекс будет использоваться (если это приемлемо) механизмом базы данных при применении объявления первичного ключа. Часто вы можете создать первичный ключ и разрешить его уникальный индекс по умолчанию, а затем создать свой собственный альтернативный индекс в этом столбце, а затем отбросить индекс по умолчанию.
Теперь для забавной части - когда вы НЕ хотите уникальный индекс первичного ключа? Вы не хотите этого и не можете терпеть одного, когда ваша таблица получает достаточное количество данных (строк), чтобы поддерживать индекс индекса слишком дорого. Это зависит от аппаратного обеспечения, механизма РСУБД, характеристик таблицы и базы данных и загрузки системы. Тем не менее, он обычно начинает проявляться, как только таблица достигает нескольких миллионов строк.
Существенной проблемой является то, что каждая вставка строки или обновление столбца первичного ключа приводит к сканированию индекса для обеспечения уникальности. Это уникальное сканирование индекса (или его эквивалент в любой из СУБД) становится намного дороже по мере роста таблицы, пока оно не станет доминирующим в производительности таблицы.
Я неоднократно занимался этой проблемой таблицами размером до двух миллиардов строк, 8 ТБ хранилища и сорокамиллионными вставками строк в день. Мне было поручено перепроектировать задействованную систему, которая включала отказ от уникального индекса первичного ключа практически в качестве первого шага. Действительно, отказ от этого индекса был необходим в производстве просто для восстановления после сбоя, прежде чем мы даже приблизились к редизайну. Эта редизайн включала поиск других способов обеспечения уникальности первичного ключа и обеспечения быстрого доступа к данным.
Первичные ключи всегда индексируются по умолчанию.
Вы можете определить первичный ключ в SQL Server 2012 с помощью SQL Server Management Studio или Transact-SQL. Создание первичного ключа автоматически создает соответствующий уникальный, кластерный или некластеризованный индекс.
PK станет кластеризованным индексом, если вы не укажете некластеризованный
Здесь переход от MSDN:
Когда вы указываете ограничение PRIMARY KEY для таблицы, механизм Database Engine обеспечивает уникальность данных, создавая уникальный индекс для столбцов первичного ключа. Этот индекс также обеспечивает быстрый доступ к данным, когда первичный ключ используется в запросах. Поэтому первичные ключи, которые выбраны, должны следовать правилам создания уникальных индексов.
Создание первичного ключа также должно автоматически создавать для него индекс.
Хорошо в SQL Server, как правило, первичный ключ автоматически индексируется. Это верно, но это не гарантирует более быстрый запрос. Первичный ключ даст вам отличную производительность, если в качестве первичного ключа есть только 1 поле. Но, когда в качестве первичного ключа используется несколько полей, индекс основывается на этих полях.
Например: Поле A, B, C является первичным ключом, поэтому, когда вы выполняете запрос на основе этих трех полей в вашей WHERE CLAUSE, производительность хорошая, НО, когда вы хотите запросить только поле С в WHERE CLAUSE, вы не получите хорошую производительность. Таким образом, чтобы повысить производительность и производительность, вам нужно будет индексировать поле C вручную.
В большинстве случаев вы не увидите проблему до тех пор, пока не получите более 1 миллиона записей.
первичные ключи автоматически индексируются
вы можете создавать дополнительные индексы с помощью pk в зависимости от вашего использования
У меня есть огромная база данных без отдельного индекса.
Каждый раз, когда я запрашиваю первичный ключ, результаты для всех интенсивных целей мгновенно.