Будет ли следующий оператор SQL автоматически создавать индекс для таблицы Table1.Table1Column или его необходимо создавать явно?
Ядром базы данных является SQL Server 2000.
CREATE TABLE [Table1] (
. . .
CONSTRAINT [FK_Table1_Table2] FOREIGN KEY
(
[Table1Column]
) REFERENCES [Table2] (
[Table2ID]
)
)
SQL Server не будет автоматически создавать индекс по внешнему ключу. Также из MSDN:
Ограничение FOREIGN KEY не обязательно должно быть связано только с ограничением PRIMARY KEY в другой таблице; его также можно определить для ссылки на столбцы ограничения UNIQUE в другой таблице. Ограничение FOREIGN KEY может содержать нулевые значения; однако, если какой-либо столбец составного ограничения FOREIGN KEY содержит нулевые значения, проверка всех значений, составляющих ограничение FOREIGN KEY, пропускается. Чтобы убедиться, что все значения составного ограничения FOREIGN KEY проверены, укажите NOT NULL во всех участвующих столбцах.
Когда я прочитал вопрос Майка, он спрашивает, создаст ли ограничение FK индекс для столбца FK в таблице, в которой находится FK (Table1). Ответ нет, и вообще. (для целей ограничения) в этом нет необходимости. Столбцы, определенные как «ЦЕЛЬ» ограничения, с другой стороны, должны быть уникальным индексом в ссылочной таблице, либо первичным ключом или альтернативный ключ. (уникальный индекс) или статус Create Constraint завершится ошибкой.
(EDIT: добавлено, чтобы явно иметь дело с комментарием ниже -) В частности, при обеспечении согласованности данных, для которой существует ограничение внешнего ключа. индекс может повлиять на производительность ограничения DRI только для удаления строки или строк на стороне FK. При использовании ограничения во время вставки или обновления процессор знает значение FK и должен проверить наличие строки в таблице, на которую ссылаются, на стороне PK. Там уже есть указатель. При удалении строки на стороне PK необходимо убедиться, что на стороне FK нет строк. Индекс может быть немного полезен в этом случае. Но это не обычный сценарий.
Однако в некоторых типах запросов обработчику запросов необходимо найти записи на множественной стороне соединения, которое использует этот столбец внешнего ключа. производительность соединения увеличивается, если для этого внешнего ключа существует индекс. Но это условие характерно для использования столбца FK в запросе на соединение, а не для существования ограничения внешнего ключа... Не имеет значения, является ли другая сторона соединения PK или просто каким-то другим произвольным столбцом. Кроме того, если вам нужно отфильтровать или упорядочить результаты запроса на основе этого столбца FK, поможет индекс... Опять же, это не имеет ничего общего с ограничением внешнего ключа для этого столбца.
Нет, создание внешнего ключа для столбца не приводит к автоматическому созданию индекса для этого столбца. Неспособность проиндексировать столбец внешнего ключа приведет к сканированию таблицы в каждой из следующих ситуаций:
В этой примерной схеме:
CREATE TABLE MasterOrder (
MasterOrderID INT PRIMARY KEY)
CREATE TABLE OrderDetail(
OrderDetailID INT,
MasterOrderID INT FOREIGN KEY REFERENCES MasterOrder(MasterOrderID)
)
OrderDetail будет сканироваться каждый раз при удалении записи в таблице MasterOrder. Вся таблица OrderDetail также будет сканироваться каждый раз, когда вы присоединяетесь к OrderMaster и OrderDetail.
SELECT ..
FROM
MasterOrder ord
LEFT JOIN OrderDetail det
ON det.MasterOrderID = ord.MasterOrderID
WHERE ord.OrderMasterID = @OrderMasterID
В целом отказ от индексации внешнего ключа является скорее исключением, чем правилом.
Дело в том, что внешний ключ не индексируется, когда он никогда не будет использоваться. Это сделало бы накладные расходы сервера на его обслуживание ненужными. Таблицы типов могут время от времени попадать в эту категорию, например:
CREATE TABLE CarType (
CarTypeID INT PRIMARY KEY,
CarTypeName VARCHAR(25)
)
INSERT CarType .. VALUES(1,'SEDAN')
INSERT CarType .. VALUES(2,'COUP')
INSERT CarType .. VALUES(3,'CONVERTABLE')
CREATE TABLE CarInventory (
CarInventoryID INT,
CarTypeID INT FOREIGN KEY REFERENCES CarType(CarTypeID)
)
Делая общее предположение, что поле CarType.CarTypeID никогда не будет обновляться, а удаление записей почти никогда не произойдет, накладные расходы сервера на поддержание индекса в CarInventory.CarTypeID будут излишними, если CarInventory никогда не будет искаться по CarTypeID.
