En el primero Column2
se agrega a la clave de índice. En el segundo caso, podría no agregarse (*) a la clave, en cuyo caso solo aparecerá en las páginas de hoja índice. Esto puede permitir que el índice sea buscado por Column1
pero evite la necesidad de volver a la tabla base (bookmark lookup/key lookup) para recuperar el valor de Column2
.
es decir, hace index2 "cobertura" para las consultas como
SELECT Column1,Column2
FROM [dbo].[MyTable]
WHERE Column1 = 'X'
Y también cubre consultas tales como
SELECT Column1,Column2
FROM [dbo].[MyTable]
WHERE Column1 = 'X' AND Column2 = 'Y'
Pero index1 también puede funcionar mejor para la segunda consulta, ya que puede buscar en las dos columnas directamente (en lugar de solo poder buscar en Column1
y luego tener que evaluar todas las filas coincidentes en el nivel de hoja de índice para ver si cumplen con el predicado Column2
). Si Column2
nunca se utiliza como un predicado de búsqueda contra ese índice y sus consultas contra ese índice no se beneficiarían de tener Column2
ordenado, entonces se debe agregar como una columna INCLUDE
-d para mantener el tamaño de la tecla hacia abajo y reducir el número de páginas en el índice.
(*) La razón por la que digo "para no ser" más arriba es porque si Column2
es (parte de) la clave del índice agrupado que will still be added there anyway para un índice no agrupado no se creó con la opción UNIQUE
.
muchas gracias. –