¿Cuál es la ventaja de utilizar una columna INCLUDE con un índice de SQL Server?

Question

CREATE NONCLUSTERED INDEX index_name 
    ON <object> (column [ ASC | DESC ] [ ,...n ]) 
    [ INCLUDE (column_name [ ,...n ]) ] 
    [ WHERE <filter_predicate> ] 

En la sintaxis anterior, especificaremos las columnas que no son de clave en el INCLUDE. ¿Cuál es la ventaja al especificar columnas que no son clave?

Answer 1

Esto almacenará los datos de la columna con el nodo de índice para un acceso rápido en las consultas que usan el índice.

Reference:

incluyen (columna [, ... n])

especifica las columnas que no son clave para ser añadió al nivel de hoja del índice no agrupado . El índice no agrupado puede ser único o no exclusivo.

Answer 2

Cuando se utiliza un índice, puede llevar a la ubicación del registro completo, o todos los campos que necesita pueden almacenarse en el índice (para que no tenga que ir al registro completo.)

En el primer caso, tiene dos lecturas mejor caso, uno para leer el índice y otro para leer el registro completo.

En el segundo caso, obtiene todo lo que necesita al leer el índice.

Puede INCLUIR columnas adicionales para almacenar con el índice si, junto con el (los) campo (s) que comprende el índice, tiene consultas completas satisfechas sin necesidad de la lectura extra para la fila.

Esto no es un problema para el índice CLUSTERED porque leer el índice es lo mismo que leer toda la fila.

Hay una ventaja especialmente grande si está leyendo varias claves de índice en una secuencia (por ejemplo, SELECCIONAR ... DESDE ... DONDE las claves ENTRE n1 Yn2) porque las lecturas de índice probablemente se almacenarán adyacentes entre sí y se puede leer con quizás solo uno o dos sectores físicos; y no tener que encontrar el resto de los registros proporciona más apalancamiento.

Answer 3

Elimina la necesidad de realizar una búsqueda de claves si la consulta utiliza la columna incluida. Ejemplo.

select ssn, firstname from myusers where ssn='111-11-1111' 

un índice apropiado sería el siguiente

create index idx_user_ssn nonclustered on myusers(ssn) include(firstname) 

Answer 4

Supongamos que usted tiene una tabla de empleados, así:

CREATE TABLE Employee(EmployeeID INT IDENTITY(1,1) PRIMARY KEY, 
         LastName VARCHAR(50), 
         FirstName VARCHAR(50), 
         HireDate DATETIME, 
         Salary DECIMAL) 

Se podría tener la clave agrupada primaria en EmployeeID, y posiblemente una clave no agrupada en (Apellido, Nombre) para poder encontrar empleados por nombre.

CREATE INDEX NameIndex ON Employee(LastName ASC, FirstName ASC) 

Ahora bien, si es necesario encontrar "Joe Murphy" y recuperar su fecha de contratación y el salario, lo que sucede es una búsqueda de índice en su clave basada en el nombre no agrupado (que es bueno), pero luego con el fin para obtener la fecha y el salario de contratación, SQL Server necesita realizar una búsqueda de marcadores en los datos reales de la tabla para obtener el registro de Joe Murphy. Es muy probable que esto genere uno o varios accesos al disco físico (lo cual es malo en términos de rendimiento).

Sin embargo: si el índice no agrupado basado en nombre también especifica "incluyen (HireDate, salario)":

CREATE INDEX NameIndex ON Employee(LastName ASC, FirstName ASC) 
     INCLUDE (HireDate, Salary) 

continuación, SQL Server se realiza una vez que se alzó Joe Murphy en el nombre no agrupado index -> todos los campos para satisfacer su consulta se encuentran en el índice no agrupado, por lo que ya no es necesario hacer una búsqueda de marcadores con uso intensivo de disco y sus consultas serán potencialmente mucho más rápidas.

La desventaja de las columnas INCLUDE es el aumento de la necesidad de espacio en disco por índices no agrupados, ya que tendrán las columnas incluidas en sus nodos a nivel de hoja. Es una compensación entre la velocidad y el tamaño (como de costumbre).

Marc

Answer 5

La ventaja del índice de inclusión es evitar el límite de tamaño.

SELECT AddressLine1, AddressLine2, City, StateProvinceID, PostalCode 
FROM Person.Address 
WHERE PostalCode BETWEEN N'98000' and N'99999' 

Aunque se podría definir todas las columnas como las columnas de clave, el tamaño de la clave sería 334 bytes.Only criterios que usamos aquí se Postalcode, Usando Postalcode en el KeyColumn y el resto en la columna clave no va a mejorar el rendimiento y la también ahorra el tamaño.

CREATE INDEX IX_Address_PostalCode 
ON Person.Address (PostalCode) 
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);