Ответ
Это зависит от СУБД.
- В MySQL с движком InnoDB: Да. При создании ограничения
FOREIGN KEYInnoDB автоматически создает индекс на столбце (или столбцах), если подходящий индекс еще не существует. Это необходимо для обеспечения целостности и производительности при операцияхDELETEиUPDATEв родительской таблице. - В других СУБД (например, PostgreSQL, SQL Server): Нет. Создание внешнего ключа не приводит к автоматическому созданию индекса. Индекс нужно создавать явно.
Практический пример и рекомендация:
-- В MySQL/InnoDB индекс создастся автоматически.
-- В PostgreSQL индекс НЕ создастся, его нужно добавить вручную.
ALTER TABLE orders
ADD CONSTRAINT fk_orders_user_id
FOREIGN KEY (user_id) REFERENCES users(id);
-- Явное создание индекса — лучшая практика для всех СУБД.
-- Это ускоряет JOIN и проверку целостности при удалении/обновлении родительской записи.
CREATE INDEX idx_orders_user_id ON orders(user_id);Почему это важно? Без индекса на столбце внешнего ключа операции DELETE из родительской таблицы (users) или JOIN с таблицей orders будут выполняться полным сканированием дочерней таблицы (orders), что крайне неэффективно на больших объемах данных.
Ответ 18+ 🔞
А, ну это, блядь, классический вопрос, который вгоняет в ступор, когда с разных СУБД пересаживаешься. Сейчас разжуём, ёпта.
Короче, ответ — зависит от того, на чём ты сидишь. Как от погоды на улице.
-
Если ты на MySQL, да ещё и на движке InnoDB (а на чём ж ещё сейчас), то — да, ёбаный в рот. Когда ты создаёшь
FOREIGN KEY, InnoDB, такой молодец, сам, без спросу, создаст индекс на этих столбцах, если его там ещё нет. Он не дурак, понимает, что без индекса проверять целостность при каждом удалении родительской записи — это пиздец какой долго, надо будет всю дочернюю таблицу целиком сканировать. Так что делает за тебя. Умная жопа. -
А вот если ты, допустим, в PostgreSQL или в SQL Server залип, то нихуя подобного. Там система более принципиальная: «Хочешь внешний ключ — пожалуйста. Хочешь, чтобы он быстро работал — сам, сука, индекс создавай. Я тебе не нянька». Серьёзно, в этих СУБД
FOREIGN KEY— это просто ограничение, а индекс к нему в комплекте не идёт. Надо руками.
Ну и что с этим делать на практике?
Смотри, вот тебе пример, чтобы совсем понятно стало. Допустим, есть таблица заказов orders, которая ссылается на юзеров users.
-- Эта строчка в MySQL/InnoDB создаст и ключ, и индекс автоматом.
-- А в PostgreSQL — только ключ. Индекс будет отсутствовать, как совесть у вора.
ALTER TABLE orders
ADD CONSTRAINT fk_orders_user_id
FOREIGN KEY (user_id) REFERENCES users(id);
-- Поэтому золотое правило, которое работает везде и спасает от пиздеца:
-- Создавай индекс на колонку внешнего ключа ВРУЧНУЮ, явно. Не надейся на авось.
CREATE INDEX idx_orders_user_id ON orders(user_id);А нахуя это вообще нужно, этот индекс? Да чтобы не было тебе хиросимы, чувак. Представь: ты удаляешь юзера из users. Без индекса на user_id в orders системе придётся пройтись по ВСЕЙ таблице заказов, от первого до последнего ряда, и проверить: «А нет ли тут заказов от этого бедолаги?». Это называется полное сканирование таблицы. На тысяче записей — похуй. На миллионе — уже овердохуища времени. То же самое с JOIN-ами. Без индекса они будут тормозить так, что волосы дыбом встанут. Так что создавай индекс всегда. Это как ремень безопасности — лучше иметь и не нуждаться, чем на первом же повороте вылететь в кювет.
