Подтвердить что ты не робот

Автоматически индексируются ли внешние ключи в SQL Server?

Будет ли следующий оператор SQL автоматически создавать индекс в Table1.Table1Column или должен быть явно создан?

Ядром базы данных является SQL Server 2000

       CREATE TABLE [Table1] (
. . .
            CONSTRAINT [FK_Table1_Table2] FOREIGN KEY 
            (
                [Table1Column]
            ) REFERENCES [Table2] (
                [Table2ID]
            )

        )

Ответ 1

SQL Server не будет автоматически создавать индекс для внешнего ключа. Также из MSDN:

Ограничение FOREIGN KEY не имеет быть связанным только с ОСНОВНЫМ КЛЮЧОМ ограничение в другой таблице; оно может также можно определить для ссылки на столбцов УНИКАЛЬНОГО ограничения в другой стол. ИНОСТРАННЫЙ КЛЮЧ ограничение может содержать нулевые значения; однако, если любой столбец составного Ограничение FOREIGN KEY содержит null значения, проверка всех значений которые составляют ИНОСТРАННЫЙ КЛЮЧ ограничение пропускается. Чтобы убедиться что все значения композита FOREIGN Ограничение KEY проверено, укажите NOT NULL на всех участвующих столбцы.

Ответ 2

Когда я прочитал вопрос Майка, он спрашивает, будет ли FK Constraint создавать индекс в столбце FK в таблице, в которой находится FK (Таблица 1). Ответ - нет, и вообще. (для целей ограничения), нет необходимости делать это. Столбец (ы), определенный как "TARGET" ограничения, с другой стороны, должен быть уникальным индексом в ссылочной таблице, либо основным ключом или альтернативный ключ. (уникальный индекс) или статус создания ограничений.

(EDIT: добавлено для явного рассмотрения комментария ниже) В частности, при обеспечении согласованности данных для ограничения внешнего ключа. индекс может повлиять на производительность DRI Constraint только для удаления строки или строк на стороне FK. При использовании ограничения во время вставки или обновления процессор знает значение FK и должен проверить наличие строки в таблице, на которую ссылается сторона PK. Там уже есть индекс. При удалении строки на стороне PK он должен убедиться, что на стороне FK нет строк. В этом случае индекс может быть незначительно полезен. Но это не общий сценарий.

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

Ответ 3

Нет, создание внешнего ключа в столбце автоматически не создает индекс в этом столбце.

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

В этой схеме примера:

CREATE TABLE MasterOrder (
   MasterOrderID INT PRIMARY KEY)

CREATE TABLE OrderDetail(
   OrderDetailID INT,
   MasterOrderID INT  FOREIGN KEY REFERENCES MasterOrder(MasterOrderID)
)

OrderDetail будет проверяться каждый раз, когда запись удаляется в таблице MasterOrder.

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