Ответ
Автоматически (по умолчанию) индексы создаются для полей с определенными ограничениями целостности (constraints). Конкретное поведение может незначительно отличаться между СУБД.
Стандартное поведение:
- PRIMARY KEY: На поле (или набор полей), объявленное как первичный ключ, всегда создается уникальный индекс. Во многих СУБД (MySQL/InnoDB, SQL Server, Oracle) это кластерный индекс (данные физически упорядочены по этому ключу).
- UNIQUE CONSTRAINT: На поле с ограничением
UNIQUEсоздается уникальный некластерный индекс.
Пример на SQL (общий синтаксис):
CREATE TABLE Employees (
EmployeeID INT PRIMARY KEY, -- Будет создан уникальный (часто кластерный) индекс
Email VARCHAR(100) UNIQUE NOT NULL, -- Будет создан уникальный индекс
FirstName VARCHAR(50) NOT NULL, -- Индекс НЕ создается автоматически
LastName VARCHAR(50) NOT NULL
);Нюансы для популярных СУБД:
- MySQL (InnoDB): Кластерный индекс создается по
PRIMARY KEY. ЕслиPRIMARY KEYне задан, используется первыйUNIQUEключ, где все столбцы имеют признакNOT NULL. Если и такого нет, InnoDB создает скрытое 6-байтное поле для кластерного индекса. - PostgreSQL: Создает уникальные индексы для
PRIMARY KEYиUNIQUE. По умолчанию индексы в PostgreSQL — некластерные. КомандаCLUSTERможет физически переупорядочить таблицу по индексу, но это не поддерживается автоматически. - SQL Server: Создает уникальный кластерный индекс для
PRIMARY KEY, если явно не указаноNONCLUSTERED. ДляUNIQUEпо умолчанию создается некластерный индекс.
Индексы для FOREIGN KEY не создаются автоматически стандартом SQL, но их часто рекомендуется создавать вручную для ускорения операций JOIN.
Ответ 18+ 🔞
А, ну это классика, блядь! Сейчас объясню, как эта магия под капотом работает, чтобы ты не ломал голову зря.
Смотри, база данных — она не дура, ёпта. Когда ты навешиваешь на поле какие-то серьёзные ограничения, она тебе автоматом подкидывает индекс, чтобы самой же не ебаться потом с поисками. Это как если бы ты в библиотеке книгу поставил на полку и сразу в карточку записал — чтобы потом не рыться по всему шкафу.
Вот смотри на этот пример, тут всё как на ладони:
CREATE TABLE Employees (
EmployeeID INT PRIMARY KEY, -- Вот тут сразу уникальный индекс прилепится, часто ещё и кластерный
Email VARCHAR(100) UNIQUE NOT NULL, -- И тут тоже уникальный индекс навесят, чтоб почты не повторялись
FirstName VARCHAR(50) NOT NULL, -- А тут нихуя не будет, ищи потом как хочешь
LastName VARCHAR(50) NOT NULL
);Главные герои тут — это PRIMARY KEY и UNIQUE. На них индексы ставятся всегда, это железно. А вот FirstName и LastName остаются голыми, как соседская Мартышлюшка после бани — хоть застрелись, ищи по ним что-то без индекса.
Теперь нюансы, потому что каждая СУБД — это хитрая жопа со своим характером:
-
MySQL (InnoDB): Тут вообще ёперный театр. Кластерный индекс (это когда данные физически в порядке лежат) делают по
PRIMARY KEY. А если ты его забыл указать — начинается цирк. Они ищут первыйUNIQUEключ, где все поляNOT NULL. Не нашли? Ну тогда, ядрёна вошь, создают какое-то скрытое поле на 6 байт и делают индекс по нему. Сам от такого охуеешь. -
PostgreSQL: Эти ребята более спокойные. Для
PRIMARY KEYиUNIQUEсоздадут уникальные индексы, но они по умолчанию некластерные. Данные в куче лежат как попало. Хочешь порядок — есть командаCLUSTER, но это ручная работа, она сама не поддерживается. -
SQL Server: Тут чётко, по-военному.
PRIMARY KEY— получай уникальный кластерный индекс, если сам не сказал иначе.UNIQUE— получай некластерный. Всё по уставу.
И вот главное, что многих наебывает: индексы для FOREIGN KEY автоматом не создаются! Да-да, доверия к СУБД тут ебать ноль. Она проверит, что в связанной таблице запись есть, но искать её будет как попало. Поэтому если ты делаешь JOIN по внешнему ключу, а индекса нет — это пиздец, волнение ебать. Производительность накроется медным тазом. Ставь индекс вручную, не будь распиздяем.
Короче, запомни: PRIMARY KEY и UNIQUE — за тобой придут с индексом. Для всего остального — терпения ноль, ебать, делай сам.