Ответ
В большинстве реляционных СУБД (как PostgreSQL, MySQL) индексы создаются автоматически для обеспечения выполнения ограничений целостности (constraints), которые требуют быстрых проверок на уникальность.
Основные случаи автоматического создания индексов:
-
PRIMARY KEY(Первичный ключ)- Всегда создает уникальный индекс (обычно B-Tree). Это необходимо для быстрого поиска строк по ключу и для гарантии его уникальности.
-
UNIQUE(Ограничение уникальности)- Всегда создает уникальный индекс для столбца или группы столбцов, чтобы эффективно проверять отсутствие дубликатов перед
INSERTилиUPDATE.
- Всегда создает уникальный индекс для столбца или группы столбцов, чтобы эффективно проверять отсутствие дубликатов перед
-
FOREIGN KEY(Внешний ключ)- Зависит от СУБД! Это важный нюанс.
- PostgreSQL: Не создает индекс для внешнего ключа автоматически. Его рекомендуется создавать вручную, чтобы избежать проблем с производительностью при
JOINилиDELETEсвязанных записей. - MySQL (InnoDB): Создает индекс для внешнего ключа автоматически.
Пример для PostgreSQL:
CREATE TABLE users (
id SERIAL PRIMARY KEY, -- Автоматически создается B-Tree индекс для id
email VARCHAR(100) UNIQUE, -- Автоматически создается B-Tree индекс для email
company_id INT REFERENCES companies(id) -- Индекс для company_id НЕ создается автоматически!
);
-- Рекомендуется создать его вручную:
CREATE INDEX idx_users_company_id ON users (company_id);Ответ 18+ 🔞
Давай разберём эту дичь про индексы, чтобы не было как с той Муму — утопили, а потом совесть заебала.
Смотри, в реляционных базах типа PostgreSQL или MySQL, индексы иногда создаются автоматом, как будто сами по себе, из воздуха. Но не просто так, а для того, чтобы быстро проверять всякие ограничения, чтобы целостность не проёбывать.
Вот основные моменты, когда база сама, без твоего ведома, натягивает индекс:
-
PRIMARY KEY(Первичный ключ)- Тут без вариантов, ёпта. Индекс создаётся всегда, и обычно уникальный B-Tree. Иначе как она будет быстро искать строки и проверять, что ты не вставляешь второй раз одну и ту же хуйню? Без индекса это был бы пиздец.
-
UNIQUE(Ограничение уникальности)- Тоже железно. Хочешь, чтобы в колонке
emailне было двухvasya@pupkin.ru? Для быстрой проверки «а нет ли уже такого?» перед каждымINSERTилиUPDATEбаза обязана навесить уникальный индекс. Иначе она будет каждый раз всю таблицу сканировать — терпения ебать ноль.
- Тоже железно. Хочешь, чтобы в колонке
-
FOREIGN KEY(Внешний ключ)- А вот тут, сука, начинается цирк! Всё зависит от СУБД! Это тот самый подводный камень, о который все бьются.
- PostgreSQL: Вежливый, но хитрый. Ограничение
FOREIGN KEYсоздаст, а вот индекс для него — НЕТ, блядь. Его надо создавать ручками, иначе при джойнах или удалениях родительских записей производительность накроется медным тазом. - MySQL (InnoDB): Более предупредительный. Для внешнего ключа индекс создаётся автоматически. Но расслабляться не стоит.
Смотри, как это выглядит на практике в PostgreSQL:
CREATE TABLE users (
id SERIAL PRIMARY KEY, -- Тут автоматом прилепится B-Tree индекс для id. Красота.
email VARCHAR(100) UNIQUE, -- И тут тоже. За уникальностью email'ов будет следить индекс.
company_id INT REFERENCES companies(id) -- А вот тут, сука, подстава! Ограничение есть, а индекса НЕТ!
);
-- Поэтому умные дяди всегда добавляют строчку:
CREATE INDEX idx_users_company_id ON users (company_id);
-- Вот теперь порядок. Не будь как Герасим, который потом метаться начал. Сделай сразу.Короче, запомни: PRIMARY KEY и UNIQUE — за тебя всё сделают. А вот с FOREIGN KEY в Постгресе — будь начеку, сам создавай индекс, и не еби себе мозг потом.