Solución:
SQL Server no creará automáticamente un índice en una clave externa. También de MSDN:
Una restricción FOREIGN KEY no tiene que estar vinculada solo a una restricción PRIMARY KEY en otra tabla; también se puede definir para hacer referencia a las columnas de una restricción ÚNICA en otra tabla. Una restricción FOREIGN KEY puede contener valores nulos; sin embargo, si alguna columna de una restricción FOREIGN KEY compuesta contiene valores nulos, se omite la verificación de todos los valores que componen la restricción FOREIGN KEY. Para asegurarse de que se verifiquen todos los valores de una restricción FOREIGN KEY compuesta, especifique NOT NULL en todas las columnas participantes.
Mientras leo la pregunta de Mike, él está preguntando si la restricción FK creará un índice en la columna FK en la tabla en la que se encuentra FK (Tabla1). La respuesta es no, y en general. (para los propósitos de la restricción), no hay necesidad de hacer esto. Las columnas definidas como el “OBJETIVO” de la restricción, por otro lado, deben ser un índice único en la tabla referenciada, ya sea una clave primaria o una tecla alternativa. (índice único) o la declaración Crear restricción fallará.
(EDITAR: Agregado para tratar explícitamente el comentario a continuación -) Específicamente, cuando se proporciona la consistencia de datos para la que existe una restricción de clave externa. un índice puede afectar el rendimiento de una restricción DRI solo para eliminaciones de una fila o filas en el lado FK. Cuando se usa la restricción, durante una inserción o actualización, el procesador conoce el valor FK y debe verificar la existencia de una fila en la tabla referenciada en el lado PK. Ya hay un índice allí. Al eliminar una fila en el lado PK, debe verificar que no haya filas en el lado FK. Un índice puede ser de poca ayuda en este caso. Pero este no es un escenario común.
Aparte de eso, en ciertos tipos de consultas, sin embargo, donde el procesador de consultas necesita encontrar los registros en el lado de muchos de una combinación que usa esa columna de clave externa. unirse al rendimiento es aumenta cuando existe un índice en esa clave externa. Pero esta condición es peculiar del uso de la columna FK en una consulta de combinación, no de la existencia de la restricción de clave externa … No importa si el otro lado de la combinación es una PK o simplemente alguna otra columna arbitraria. Además, si necesita filtrar u ordenar los resultados de una consulta basada en esa columna FK, un índice ayudará … De nuevo, esto no tiene nada que ver con la restricción de clave externa en esa columna.
No, la creación de una clave externa en una columna no crea automáticamente un índice en esa columna. No indexar una columna de clave externa provocará un escaneo de la tabla en cada una de las siguientes situaciones:
- Cada vez que se elimina un registro de la tabla referenciada (principal).
- Cada vez que las dos tablas se unen en la clave externa.
- Cada vez que se actualiza la columna FK.
En este esquema de ejemplo:
CREATE TABLE MasterOrder (
MasterOrderID INT PRIMARY KEY)
CREATE TABLE OrderDetail(
OrderDetailID INT,
MasterOrderID INT FOREIGN KEY REFERENCES MasterOrder(MasterOrderID)
)
OrderDetail se escaneará cada vez que se elimine un registro en la tabla MasterOrder. También se escaneará toda la tabla OrderDetail cada vez que se una a OrderMaster y OrderDetail.
SELECT ..
FROM
MasterOrder ord
LEFT JOIN OrderDetail det
ON det.MasterOrderID = ord.MasterOrderID
WHERE ord.OrderMasterID = @OrderMasterID
En general, no indexar una clave externa es más una excepción que una regla.
Un caso para no indexar una clave externa es donde nunca se utilizaría. Esto haría innecesaria la sobrecarga del servidor de mantenerlo. Las tablas de tipos pueden caer en esta categoría de vez en cuando, un ejemplo podría ser:
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)
)
Suponiendo que el campo CarType.CarTypeID nunca se actualizará y que la eliminación de registros casi nunca lo será, la sobrecarga del servidor de mantener un índice en CarInventory.CarTypeID sería innecesaria si CarInventory nunca fuera buscado por CarTypeID.