а таких уже не существует;

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

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

Изменить: дополнительный вопрос - будет ли это вредно для дополнительной индексации первичного ключа?

Ответы на вопрос(11)

в SQL Server, как правило, первичный ключ автоматически индексируется. Это правда, но это не гарантирует более быстрый запрос. Первичный ключ даст вам отличную производительность, когда в качестве первичного ключа будет только 1 поле. Но когда в качестве первичного ключа используются несколько полей, индекс основывается на этих полях.

Например: поля A, B, C являются первичным ключом, поэтому, когда вы делаете запрос на основе этих 3 полей в WHERE CLAUSE, производительность хорошая, НО, когда вы хотите запросить только поле C в WHERE CLAUSE, вы не получится хорошей производительности. Таким образом, чтобы повысить производительность, вам нужно вручную проиндексировать поле C.

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

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

 Grant20 янв. 2009 г., 19:31
Я посмотрю на план запроса, если что-то пойдет не так.
 SQLMenace20 янв. 2009 г., 19:31
Это потому, что PK является кластерным индексом, посмотрите на ваш план запроса

PRIMARY KEY или жеUNIQUE ограничение заставляет SQL Server автоматически создавать индекс.

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

Отсюда создание ограничения будет:

вызвать создание индекса с тем же именемотрицать удаление созданного индекса, так как без него не может существовать ограничение

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

Итак, есть ли реальная разница междуPRIMARY KEY или жеUNIQUE INDEX:

NULL значения не допускаются вPRIMARY KEY, но разрешено вUNIQUE индекс; и, как в множестве операторов (UNION, EXCEPT, INTERSECT), здесьNULL = NULL это означает, что вы можете иметь только одно значение как дваNULLs найдены как дубликаты друг друга;единственныйPRIMARY KEY может существовать в таблице в то время как999 уникальные индексы могут быть созданыкогдаPRIMARY KEY ограничение создано, оно создается как кластеризованное, если в таблице уже нет кластеризованного индекса илиNONCLUSTERED используется в его определении; когдаUNIQUE Индекс создан, он создан какNONCLUSTERED если это не является специфичным дляCLUSTERED а таких уже не существует;

Вы можете создавать дополнительные индексы, используя ПК в зависимости от вашего использования

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

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

Дополнительный индекс не приносит пользы, но единственный вред (очень маленький) - это дополнительный размер файла и накладные расходы на создание строк.

 Pacerier06 июл. 2012 г., 09:40
Ущерб неиспользованным индексам действительно очень вреден. С одной стороны, индексы съедают память. С другой стороны, это замедляет записи и обновления. Всегда удаляйте индексы, которые не будут использоваться.

если вы не укажете не кластеризованный индекс

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

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

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

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

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

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

в-большой.

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

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

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

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

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

 quillbreaker10 мая 2013 г., 00:16
Что если ключ является автоинкрементным ключом типа int или bigint? SQL Server достаточно умен, чтобы в этом случае не выполнять уникальное сканирование индекса?
 user56586909 мар. 2015 г., 19:59
@quillbreaker: анIDENTITY поле не гарантируется быть уникальным. В конце концов, пользователи могут вставлять повторяющиеся значения, если они пользовательIDENTITY_INSERT.
 Max Candocia29 нояб. 2017 г., 17:45
Если вы не отмените ограничение уникальности, не будет ли намного больше затрат на проверку каждой строки на уникальность?
 Charles Burns21 апр. 2017 г., 00:32
Я знаю, что это древняя тема, но я не понимаю, как проверка уникальности одного индекса была бы такой нагрузкой на систему. Сканирование B + дерева должно быть O (log n) * v, где v ограничено накладными расходами для фрагментации индекса, несовершенного баланса дерева и т. Д. Таким образом, 2 миллиарда строк будут основаны на журнале 2 из 2 000 000 000 (около 31 поиска) раз, скажем, 2, 3 или даже 10. 40M вставок в день - это примерно 462 / сек, ~ 100 операций ввода-вывода на одну вставку ... Ааа ... Ох. Понимаю. И это было до широко распространенных SSD.

он также должен автоматически создать индекс для него.

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

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

MSDN:

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

Ваш ответ на вопрос