Создание первичных ключей

Как установить (объединить) два первичных ключа в таблице

для небольшого приложения, связанного с продажами, мы разработали базу данных с использованием логической модели данных. Вышла на сцену, чтобы преобразовать в физическую модель. При создании таблицы в SQL Server Management Studio Express в соответствии с нашей логической моделью данных нам необходимо объединить два атрибута для формирования уникального идентификатора. Можно ли объединить два первичных ключа и установить его?

но, наблюдая образец Нортвинда, мы обнаружили, что в ORDER DETAILS таблица, мы видим два первичных ключа Order Id & Product Id . По таблице правил не может быть двух первичных ключей. Так как это случилось в Нортвинде?

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

кто-то дал предложение как

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

будет ли это работать ??

Теперь у моей таблицы есть 2 ПК в SSMS . это действительно или это просто комбинация 2 pks

4 ответов

самый простой способ-использовать команду T-SQL в SSMS Express, а не пытаться использовать визуальные конструкторы.

после того, как вы разработали и создали свою таблицу, попробуйте что-то вроде этого:

нельзя создать два первичных ключа в таблице. Вы можете объединить два столбца в таблице и сделать как один первичный ключ

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

Похожие публикации:

Remarks

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

• Каждое новое значение будет сформировано на основе текущих аргументов seed и increment.

• Каждое новое значение для определенной транзакции будет отлично от других параллельных транзакций для таблицы.

Свойство идентификаторов столбца не гарантирует следующее.

Уникальность значения — уникальность значения следует обеспечить с помощью ограничения PRIMARY KEY или UNIQUE либо индекса UNIQUE.

Примечание

Azure Synapse Analytics не поддерживает ограничения PRIMARY KEY или UNIQUE либо индекс UNIQUE. Дополнительные сведения см. в статье .

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

• Последовательные значения после перезапуска сервера или других ошибок — SQL Server может сохранять значения идентификаторов в кэше для обеспечения высокой производительности, и некоторые из присвоенных значений могут быть потеряны при сбое базы данных или перезагрузке сервера. Это может вызвать пропуски в значениях идентификатора при вставке. Если пропуски недопустимы, приложение должно использовать собственный механизм для создания значений ключей. Использование генератора последовательностей с параметром NOCACHE может привести к ограничению пропусков в незафиксированных транзакциях.

• Повторное использование значений — свойства идентификаторов, созданные конкретным свойством идентификатора с заданными аргументами seed и increment, не используются повторно подсистемой. Если определенная инструкция вставки завершается с ошибкой или производится ее откат, использованные значения идентификаторов не будут созданы повторно. Это может привести к появлению пропусков при создании последующих значений идентификаторов.

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

Если таблица со столбцом идентификаторов опубликована для репликации, этот столбец должен обслуживаться в соответствии с типом репликации. Дополнительные сведения см. в статье Репликация столбцов идентификаторов.

Для каждой таблицы можно создать только один столбец идентификаторов.

В таблицах, оптимизированных для памяти, в качестве начального значения и значения приращения должно быть задано 1,1. Установка для параметров seed или increment значения, отличного от 1, приводит к следующей ошибке: «Использование для параметров seed и increment значений, отличных от 1, не поддерживается в таблицах, оптимизированных для памяти».

Составной ключ (composite key)

Что касается составного ключа — это несколько первичных ключей в таблице. Таким образом, создав composite key, уникальность записи будет проверяться по полям, которые объединенные в этот ключ.

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

create table test(field_1 int, field_2 text, field_3 bigint, primary key (field_1, field_3));

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

Это все, что касается ключей в SQL. Это небольшое пособие — подготовка к статье связи sql где мы подробно рассмотрим как объединять таблицы, чтобы они составляли единую базу данных.

Составные индексы

Рассмотрим такой запрос:

SELECT * FROM users WHERE age = 29 AND gender = 'male'

Нам следует создать составной индекс на обе колонки:

CREATE INDEX age_gender ON users(age, gender);

Устройство составного индекса

Чтобы правильно использовать составные индексы, необходимо понять структуру их хранения. Все работает точно так же, как и для обычного индекса. Но для значений используются значения всех входящих колонок сразу. Для таблицы с такими данными:

id | name   | age | gender
1  | Den    | 29 | male
2  | Alyona | 15 | female
3  | Putin  | 89 | tsar
4  | Petro  | 12 | male

значения составного индекса будут такими:

age_gender
12male
15female
29male
89tsar

Это означает, что очередность колонок в индексе будет играть большую роль. Обычно колонки, которые используются в условиях WHERE, следует ставить в начало индекса. Колонки из ORDER BY — в конец.

Поиск по диапазону

Представим, что наш запрос будет использовать не сравнение, а поиск по диапазону:

SELECT * FROM users WHERE age <= 29 AND gender = 'male'

Тогда MySQL не сможет использовать полный индекс, т.к. значения gender будут отличаться для разных значений колонки age. В этом случае база данных попытается использовать часть индекса (только age), чтобы выполнить этот запрос:

age_gender
12male
15female
29male
89tsar

Сначала будут отфильтрованы все данные, которые подходят под условие age <= 29. Затем, поиск по значению “male” будет произведен без использования индекса.

Сортировка

Составные индексы также можно использовать, если выполняется сортировка:

SELECT * FROM users WHERE gender = 'male' ORDER BY age

В этом случае нам нужно будет создать индекс в другом порядке, т.к. сортировка (ORDER) происходит после фильтрации (WHERE):

CREATE INDEX gender_age ON users(gender, age);

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

Колонок в индексе может быть больше, если требуется:

SELECT * FROM users WHERE gender = 'male' AND country = 'UA' ORDER BY age, register_time

В этом случае следует создать такой индекс:

CREATE INDEX gender_country_age_register ON users(gender, country, age, register_time);

Выбор индексов в MySQL

В самом простом случае, индекс необходимо создавать для тех колонок, которые присутствуют в условии WHERE.

Рассмотрим запрос из примера:

SELECT * FROM users WHERE age = 29

Нам необходимо создать индекс на колонку age:

CREATE INDEX age ON users(age);

После этой операции MySQL начнет использовать индекс age для выполнения подобных запросов. Индекс будет использоваться и для выборок по диапазонам значений этой колонки:

SELECT * FROM users WHERE age < 29

Сортировка

Для запросов такого вида:

SELECT * FROM users ORDER BY register_date

действует такое же правило – создаем индекс на колонку, по которой происходит сортировка:

CREATE INDEX register_date ON users(register_date);

Внутренности хранения индексов

Представим, что наша таблица выглядит так:

id | name   | age
1  | Den    | 29
2  | Alyona | 15
3  | Putin  | 89
4  | Petro  | 12

После создания индекса на колонку age, MySQL сохранит все ее значения в отсортированном виде:

age index
12
15
29
89

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

age index и связь с записями
12: 4
15: 2
29: 1
89: 3

Уникальные индексы

MySQL поддерживает уникальные индексы. Это удобно для колонок, значения в которых должны быть уникальными по всей таблице. Такие индексы улучшают эффективность выборки для уникальных значений. Например:

SELECT * FROM users WHERE email = '';

CREATE UNIQUE INDEX email ON users(email)

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

Пример

Рассмотрим SQL пример CREATE TABLE.

PgSQL

CREATE TABLE suppliers
( supplier_id int NOT NULL,
supplier_name char(50) NOT NULL,
contact_name char(50)
);

1 2 3 4 5

CREATETABLEsuppliers (supplier_idintNOT NULL, supplier_namechar(50)NOT NULL, contact_namechar(50) );

Этот SQL пример CREATE TABLE создает таблицу suppliers, которая имеет 3 столбца.

• Первый столбец называется supplier_id, который создается в виде числового типа (максимум 10 цифр в длину) и не может содержать нулевые значения
• Второй столбец называется supplier_name, который представляет собой тип данных char (максимальная длина 50 символов) и также не может содержать нулевые значения
• Третий столбец называется contact_name, который является типом данных char, но может содержать нулевые значения

Теперь единственная проблема с этим SQL оператором CREATE TABLE заключается в том, что вы не определили первичный ключ для таблицы. Мы могли бы изменить этот SQL оператор CREATE TABLE и определить supplier_id в качестве первичного ключа следующим образом.

PgSQL

CREATE TABLE suppliers
( supplier_id int NOT NULL,
supplier_name char(50) NOT NULL,
contact_name char(50),
CONSTRAINT suppliers_pk PRIMARY KEY (supplier_id)
);

1 2 3 4 5 6

CREATETABLEsuppliers (supplier_idintNOT NULL, supplier_namechar(50)NOT NULL, contact_namechar(50), CONSTRAINTsuppliers_pkPRIMARYKEY(supplier_id) );

Подробнее о первичных ключах.Подробнее о внешних ключах..

SQL Учебник

SQL ГлавнаяSQL ВведениеSQL СинтаксисSQL SELECTSQL SELECT DISTINCTSQL WHERESQL AND, OR, NOTSQL ORDER BYSQL INSERT INTOSQL Значение NullSQL Инструкция UPDATESQL Инструкция DELETESQL SELECT TOPSQL MIN() и MAX()SQL COUNT(), AVG() и …SQL Оператор LIKESQL ПодстановочныйSQL Оператор INSQL Оператор BETWEENSQL ПсевдонимыSQL JOINSQL JOIN ВнутриSQL JOIN СлеваSQL JOIN СправаSQL JOIN ПолноеSQL JOIN СамSQL Оператор UNIONSQL GROUP BYSQL HAVINGSQL Оператор ExistsSQL Операторы Any, AllSQL SELECT INTOSQL INSERT INTO SELECTSQL Инструкция CASESQL Функции NULLSQL ХранимаяSQL Комментарии

5 последних уроков рубрики «Разное»

• Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

• Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

  Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

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

• Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

8 ответов

Решение

Я бы использовал составной (многостолбцовый) ключ.

Таким образом, вы можете иметь t1ID и t2ID в качестве внешних ключей, указывая также на их соответствующие таблицы.

275

2011-04-29 18:47

Я бы не стал делать первичный ключ таблицы «info» составным из двух значений из других таблиц.

Другие могут лучше сформулировать причины, но неправильно иметь столбец, который на самом деле состоит из двух частей информации. Что делать, если вы хотите по какой-то причине отсортировать по идентификатору из второй таблицы? Что если вы хотите посчитать, сколько раз значение из любой таблицы присутствует?

Я бы всегда держал их в виде двух разных столбцов. Вы можете использовать первичный ключ с двумя столбцами в mysql …PRIMARY KEY(id_a, id_b)… но я предпочитаю использовать уникальный индекс из двух столбцов и иметь поле первичного ключа с автоматическим приращением.

18

2011-04-29 19:27

Синтаксис например::

приведенный выше пример будет работать, если вы пишете его во время создания таблицы, например:

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

12

2013-03-26 16:58

Составные первичные ключи — это то, что вам нужно, когда вы хотите создать связь «многие ко многим» с таблицей фактов. Например, у вас может быть пакет аренды на время отпуска, который включает в себя несколько свойств. С другой стороны, недвижимость также может быть доступна как часть ряда пакетов аренды, либо самостоятельно, либо вместе с другими объектами. В этом сценарии вы устанавливаете связь между свойством и пакетом аренды с помощью таблицы фактов свойства / пакета. Связь между свойством и пакетом будет уникальной, вы можете присоединиться только с помощью property_id с таблицей свойств и / или package_id с таблицей пакетов. Каждое отношение уникально, а ключ auto_increment является избыточным, поскольку он не будет отображаться ни в одной другой таблице. Следовательно, определение составного ключа является ответом.

4

2013-03-12 18:43

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

Например, в каждом штате США есть набор уникальных округов Конгресса. Хотя во многих штатах CD-5 может быть отдельно, в любом из 50 штатов никогда не будет более одного CD-5, и наоборот. Поэтому создание поля автонумерации для Массачусетса CD-5 было бы излишним.

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

Поэтому, хотя я не отвечаю на первоначальный вопрос, я, безусловно, ценю прямой ответ Адама.

3

2013-10-17 11:15

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

3

2017-08-23 06:16

@AlexCuse Я хотел добавить это как комментарий к вашему ответу, но сдался после нескольких неудачных попыток добавить новые строки в комментарии.

Тем не менее, t1ID уникален в table_1, но это не делает его уникальным и в таблице INFO.

Например:

Таблица_1 имеет:Поле идентификатора1 А2 Б

Таблица_2 имеет:Поле идентификатора1 х2 года

ИНФО тогда может иметь:поле t1ID поле t2ID1 1 некоторые1 2 данных2 1 в каждом2 2 ряд

Таким образом, в таблице INFO для уникальной идентификации строки вам нужны и t1ID, и t2ID.

1

2014-06-05 13:45

1

2012-02-07 08:32

Первичные ключи

Первичный ключ (Primary Key) — это особый тип индекса, который является идентификатором записей в таблице. Он обязательно уникальный и указывается при создании таблиц:

CREATE TABLE `users` (

 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

 `email` varchar(128) NOT NULL,

 `name` varchar(128) NOT NULL,

 PRIMARY KEY (`id`),

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf-8

При использовании таблиц InnoDB всегда определяйте первичные ключи. Если первичного ключа нет, MySQL все равно создаст виртуальный скрытый ключ.

Кластерные индексы

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

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

Первичные ключи таблиц InnoDB являются кластерными. Поэтому выборки по ним происходят очень эффективно.

Синтаксис идентификаторов MySQL CREATE TABLE

CREATE TABLE database_name.table_name

CREATE TABLE database_name.schema_name.table_name

MySQL использует обратные кавычки вместо квадратных скобок в именах таблиц и столбцов

-- MySQL CREATE TABLE
CREATE TABLE `testdatabase`.`person` (
  `BusinessEntityID` INT NOT NULL,
  `PersonType` NCHAR(2) NOT NULL,
  `Title` VARCHAR(8) NULL,
  `FirstName` NVARCHAR(50) NOT NULL,
  `MiddleName` VARCHAR(50) NULL,
  `LastName` VARCHAR(50) NOT NULL,
  `Suffix` NVARCHAR(10) NULL,
  `EmailPromotion` INT NOT NULL,
  `ModifiedDate` DATETIME NOT NULL DEFAULT NOW(),
  PRIMARY KEY (`BusinessEntityID`));

-- T-SQL CREATE TABLE
CREATE TABLE ..(
	  NOT NULL,
	 (2) NOT NULL,
	 (8) NULL,
	 (50) NOT NULL,
	 (50) NULL,
	 (50) NOT NULL,
	 (10) NULL,
	  NOT NULL,
	  NOT NULL DEFAULT GETDATE(),
 CONSTRAINT  PRIMARY KEY  
  (
	 ASC
  )
) ON 

MySQL использует «TEMPORARY» вместо ‘#’ для временных таблиц

-- Временная таблица в MySQL
CREATE TEMPORARY TABLE `MyTempTable`

-- Временная таблица в T-SQL
CREATE TABLE #MyTempTable

1.2.5. Первичный ключ

Мы уже достаточно много говорили про ключевые поля, но ни разу их не использовали. Самое интересное, что все работало. Это преимущество, а может недостаток базы данных Microsoft SQL Server и MS Access. В таблицах Paradox такой трюк не пройдет и без наличия ключевого поля таблица будет доступна только для чтения.

В какой-то степени ключи являются ограничениями, и их можно было рассматривать вместе с оператором CHECK, потому что объявление происходит схожим образом и даже используется оператор CONSTRAINT. Давайте посмотрим на этот процесс на примере. Для этого создадим таблицу из двух полей «guid» и «vcName». При этом поле «guid» устанавливается как первичный ключ:

CREATE TABLE Globally_Unique_Data
(
 guid uniqueidentifier DEFAULT NEWID(),
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (Guid)
)

Самое вкусное здесь это строка CONSTRAINT. Как мы знаем, после этого ключевого слова идет название ограничения, и объявления ключа не является исключением. Для именования первичного ключа, я рекомендую использовать именование типа PK_имя, где имя – это имя поля, которое должно стать главным ключом. Сокращение PK происходит от Primary Key (первичный ключ).

После этого, вместо ключевого слова CHECK, которое мы использовали в ограничениях, стоит оператор PRIMARY KEY, Именно это указывает на то, что нам необходима не проверка, а первичный ключ. В скобках указывается одно, или несколько полей, которые будут составлять ключ.

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

В данном примере, в качестве первичного ключа выступает поле типа uniqueidentifier (GUID). Значение по умолчанию для этого поля – результат выполнения серверной процедуры NEWID.

Внимание

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

Для простоты примеров, в качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше, если он будет типа «autoincrement» (автоматически увеличивающееся/уменьшающееся число). В MS SQL Server таким полем является IDENTITY, а в MS Access это поле типа «счетчик».

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

CREATE TABLE Товары
(
  id int IDENTITY(1, 1),
  товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY (id)
)

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

Первичный ключ может состоять из более, чем одной колонки. Следующий пример создает таблицу, в которой поля «id» и «Товар» образуют первичный ключ, а значит, будет создан индекс уникальности на оба поля:

CREATE TABLE Товары1
(
  id int IDENTITY(1, 1),
  Товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY 
         (id, )
)

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

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

Практическое упражнение № 3

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

PgSQL

CREATE TABLE departments
( department_id int NOT NULL,
department_name char(50) NOT NULL,
CONSTRAINT departments_pk PRIMARY KEY (department_id)
);

1 2 3 4 5

CREATETABLEdepartments (department_idintNOT NULL, department_namechar(50)NOT NULL, CONSTRAINTdepartments_pkPRIMARYKEY(department_id) );

Решение для упражнения № 3

Инструкция SQL CREATE TABLE для таблицы employees.

PgSQL

CREATE TABLE employees
( employee_number int NOT NULL,
employee_name char(50) NOT NULL,
department_id int,
salary int,
CONSTRAINT employees_pk PRIMARY KEY (employee_number),
CONSTRAINT fk_departments
FOREIGN KEY (department_id)
REFERENCES departments(department_id)
);

1 2 3 4 5 6 7 8 9 10

CREATETABLEemployees (employee_numberintNOT NULL, employee_namechar(50)NOT NULL, department_idint, salaryint, CONSTRAINTemployees_pkPRIMARYKEY(employee_number), CONSTRAINTfk_departments FOREIGNKEY(department_id) REFERENCESdepartments(department_id) );

ОСНОВНОЙ КЛЮЧ

SQL PRIMARY KEY — это столбец в таблице, который должен содержать уникальное значение, которое можно использовать для уникальной идентификации каждой строки таблицы.

Тем не менее, SQL поддерживает первичные ключи напрямую с ограничением PRIMARY KEY.

Функционально это то же самое, что и ограничение UNIQUE, за исключением того, что для данной таблицы можно определить только один PRIMARY KEY. PRIMARY KEY не допускает значения NULL.

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

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

Первичные ключи могут быть указаны во время CREATING TABLE или во время изменения структуры существующей таблицы с помощью инструкции ALTER TABLE.

Это ограничение является комбинацией ограничения NOT NULL и ограничения UNIQUE. Это ограничение гарантирует, что конкретный столбец или комбинация из двух или более столбцов для таблицы имеют уникальную идентификацию, которая помогает легче и быстрее найти конкретную запись в таблице.

Синтаксис:

 CREATE TABLE <имя_таблицы>
column1 data_type  NOT NULL PRIMARY KEY,
column2 data_type ,
...);

Параметры:

название	Описание
table_name	Имя таблицы, в которой хранятся данные.
column1, column2	Наименование столбцов таблицы.
тип данных	Это char, varchar, целое число, десятичное число, дата и многое другое.
размер	Максимальная длина столбца таблицы.

Overhead

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

Создавайте только необходимые индексы, чтобы не расходовать зря ресурсы сервера. Контролируйте размеры индексов для Ваших таблиц:

mysql> show table status;

+-------------------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
| Name              | Engine | Version | Row_format | Rows   | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation       | Checksum | Create_options | Comment |
+-------------------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
...
| users             | InnoDB |      10 | Compact    |    314 |            208 |       65536 |               0 |        16384 |         0 |            355 | 2014-07-11 01:12:17 | NULL        | NULL       | utf8_general_ci |     NULL |                |         |
+-------------------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
18 rows in set (0.06 sec)