Regla dura y rápida para incluir columnas en el índice

¿Existe alguna regla estricta y rápida para decidir qué columnas y en qué orden se debe incluir en el índice no agrupado. Estaba leyendo esta publicación https://stackoverflow.com/questions/1307990/why-use-the-include-clause-when-creating-an-index y encontré eso para la siguiente consulta:

SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5

El póster sugería hacer un índice como este:

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(EmployeeID, DepartmentID)
  INCLUDE (Lastname)

aquí viene mi pregunta por qué no podemos hacer un índice como este

CREATE NONCLUSTERED INDEX NC_EmpDep 
      ON Employee( EmployeeID, DepartmentID, LastName)

o

    CREATE NONCLUSTERED INDEX NC_EmpDep 
          ON Employee( EmployeeID, LastName)
INCLUDE (DepartmentID)

y qué hace que el póster decida mantener la columna Apellido incluida. ¿Por qué no otras columnas? y cómo decidir en qué orden debemos mantener las columnas allí?

Esa sugerencia de índice de marc_s está mal. He agregado un comentario. (¡Y fue mi respuesta aceptada también!)

El índice para esta consulta sería

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(DepartmentID)
  INCLUDE (Lastname, EmployeeID)

Un índice es típicamente

CREATE INDEX <name> ON <table> (KeyColList) INCLUDE (NonKeyColList)

Dónde:

• KeyColList = Columnas clave = utilizadas para la restricción de filas y el procesamiento
  DONDE, UNIR, ORDENAR POR, GRUPO POR, etc.
• NonKeyColList = Columnas sin clave = utilizadas en SELECT y agregación (por ejemplo, SUM (col)) después de la selección / restricción

JNK y gbn han dado excelentes respuestas, pero también vale la pena considerar el panorama general, no solo centrarse en una sola consulta. Aunque esta consulta particular podría beneficiarse de un índice (# 1):

Employee(DepartmentID) INCLUDE (Lastname, EmployeeID)

Este índice no ayuda en absoluto si la consulta cambia ligeramente, como por ejemplo:

SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5 AND LastName = 'Smith'

Esto necesitaría el índice (# 2):

Employee(DepartmentID, LastName) INCLUDE (EmployeeID)

Imagine que tiene 1,000 empleados en el Departamento 5. Usando el índice # 1, para encontrar todos los Smiths, necesitaría buscar a través de las 1,000 filas en el Departamento 5, ya que las columnas incluidas no son parte de la clave. Usando el índice # 2, puede buscar directamente al Departamento 5, Apellido Smith.

Por lo tanto, el índice n. ° 2 es más útil para atender una gama más amplia de consultas, pero el costo es una clave de índice más hinchada, lo que hará que las páginas del índice que no son hojas sean más grandes. Cada sistema será diferente, por lo que no hay una regla general aquí.

Como nota al margen, vale la pena señalar que si EmployeeID era la clave de agrupación para esta tabla, suponiendo un índice agrupado, entonces no necesita incluir EmployeeID; está presente en todos los índices no agrupados, lo que significa que el índice # 2 podría simplemente ser

Employee(DepartmentID, LastName)

No estoy seguro de cómo conseguiste ese primero. Para mí, para esa consulta, usaría:

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(DepartmentID)
  INCLUDE (EmployeeID, Lastname)

No hay una "regla dura y rápida" para prácticamente cualquier cosa en SQL.

Pero, para su ejemplo, el único campo que usará el índice es DepartmentIDporque está en la WHEREcláusula.

Los otros campos solo necesitan ser fácilmente accesibles desde allí. Seleccione en función de DepartmentIDentonces INCLUDEtiene esos campos en el nodo hoja del índice.

No desea utilizar sus otros ejemplos porque no funcionarían para este índice.

Piense en un índice como una guía telefónica. La mayoría de las guías telefónicas están ordenadas por apellido, nombre, inicial del segundo nombre. Si conoce el nombre de alguien, pero no su apellido, la guía telefónica no le sirve de nada, ya que no puede buscar el nombre basado en el orden del índice de la guía telefónica.

Los INCLUDEcampos son como el número de teléfono, dirección, etc. otra información para cada entrada en el libro.

EDITAR:

Para aclarar aún más por qué no usar:

CREATE NONCLUSTERED INDEX NC_EmpDep 
          ON Employee( EmployeeID, LastName)
INCLUDE (DepartmentID)

Este índice solo es útil si tiene uno EmployeeIDo AMBOS EmployeeID y LastNameen su WHEREcláusula. Esto es prácticamente lo OPUESTO de lo que necesita para esta consulta.

Creo que aún podría usar el índice (employee_id, department_id), pero tendría que incluir una línea 'ficticia' en la frase where, como: "employee_id = employee_id)

• tener un índice en (employee_id, departemnent_id),
• tener que buscar / restringir solo en un departamento_id
• sabiendo que no usará el índice desde un orden incorrecto (o las cosas han cambiado por ahora, y el siguiente "truco" ya no es necesario. ¿Soy un "viejo"?) .

• Utilice el "viejo" truco?

  seleccione * de Employee emp
  donde emp.employee_id = emp.employee_id
  y emp.department_id = 5
  

(Por lo tanto, no me estoy centrando en la parte de inclusión aquí de Apellido, sino en el sí / no se usa la clave).

Saludos cordiales,

Miguell