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

Каждая таблица должна иметь PRIMARY KEY.

Много типов запросов ускорены разумным выбором ИНДЕКСА. Это может быть, что лучший индекс является первичным ключом. Моя точка - то, что запрос является основным фактором в том, использовать ли PK для его индекса.

Различия

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

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

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

Когда и что использовать

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

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

Что лучше?

На самом деле ни одного - у каждого своя цель. И дело не в том, что вы действительно можете выбрать то или иное.

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

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

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

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

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

Например, если у вас есть индекс по столбцам (A, B, C), этот индекс можно использовать, даже если вы фильтруете только по A, потому что это первый столбец в индексе. Точно так же его можно использовать, если вы фильтруете как по A, так и по B. Однако его нельзя использовать, если вы фильтруете только по B или C, потому что они не являются префиксом в списке столбцов - вам нужен другой индекс для размещения этого .

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

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

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

Что касается "первичных" ключей. Они не являются "особым" типом ключей. Первичный ключ - это просто любой ключ-кандидат таблицы. В большинстве СУБД SQL существует по крайней мере два способа создания ключей-кандидатов, и это либо использование ограничения PRIMARY KEY, либо использование ограничения UNIQUE на столбцах NOT NULL. Очень широко распространено мнение, что каждая таблица SQL имеет ограничение PRIMARY KEY. Использование ограничения PRIMARY KEY - это общепринятая мудрость и вполне разумный поступок, но в целом это не имеет никакого практического или логического значения, поскольку большинство СУБД рассматривают все ключи как равные. Безусловно, каждая таблица должна иметь хотя бы один ключ-кандидат, но будет ли этот ключ (ключи) управляться ограничениями PRIMARY KEY или UNIQUE, обычно не имеет значения. В принципе, важны именно ключи-кандидаты, а не "первичные" ключи.

Это может помочь Назад к основам: разница между первичным ключом и уникальным индексом

Различия между двумя являются:

1. Столбцы, составляющие первичный ключ таблицы, не могут иметь значение NULL, поскольку по определению первичный ключ не может быть NULL, поскольку он помогает однозначно идентифицировать запись в таблице. Столбцы, составляющие уникальный индекс, могут иметь значение NULL. Здесь стоит упомянуть, что разные СУБД обрабатывают это по-разному -> в то время как SQL Server и DB2 не допускают более одного значения NULL в столбце уникального индекса, Oracle допускает несколько значений NULL. Это одна из вещей, на которую следует обратить внимание при проектировании / разработке / переносе приложений в СУБД.
2. В таблице может быть только один первичный ключ, а в таблице может быть определено множество уникальных индексов (при необходимости).
3. Кроме того, в случае SQL Server, если вы выбираете параметры по умолчанию, тогда первичный ключ создается как кластеризованный индекс, а уникальный индекс (ограничение) создается как некластеризованный индекс. Это просто поведение по умолчанию, и при необходимости его можно изменить во время создания.