bueno/no importa/es malo incluir la clave principal en el índice de cobertura?

Question

es good o doesn't matter o bad para INCLUIR la clave principal en un índice de cobertura ??

CREATE NONCLUSTERED INDEX index_name_here ON dbo.table_name_here 
(column_to_index_here) 
INCLUDE (primary_key_column,other_column_here) 
WITH(STATISTICS_NORECOMPUTE=OFF, IGNORE_DUP_KEY=OFF, --<default junk from SSMS 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
GO 

Estoy pensando que no importa, ya que el PK estará en el índice de todos modos.

EDIT - aclarar.
mi primary_key_column está agrupado, pero puede explicar/dar información cuando no sea así.

que se unirá a dbo.table_name_here en la columna de la column_to_index_here y será luego unirse a otras tablas en primary_key_column y other_column_here.

Answer 1

Si se está agrupando en su PK, entonces no importa. SQL Server no tendrá en cuenta ya que todos los índices no agrupados contienen la clave de índice agrupado para esa fila como parte de su definición.

No utilizará ningún espacio adicional en el índice, pero es redundante incluirlo en la definición.

Si su PK no está incluido en su índice agrupado, entonces solo debe incluirlo si necesita recuperar ese campo como parte de la misma consulta que usa el índice.

También tenga en cuenta cuando INCLUDE un campo en un índice, NO está en los nodos de hoja, es decir, el índice no está ordenado en ese valor.

Answer 2

Solo tiene que incluirlo si realmente lo necesita para "cubrir" la consulta, de lo contrario, está desperdiciando espacio. El objetivo de un índice de cobertura es que elimine la necesidad de buscar marcadores en la tabla base, por lo que no hay ningún uso para la clave principal en ese sentido.

Answer 3

ya que el PK estará en el índice de todos modos.

Suponiendo que se refiere a que el PK está en otro índice con esa afirmación, si incluye o no la clave principal en este índice depende de si va a seleccionarlo en sus consultas. Si va a seleccionarlo, inclúyalo en el índice; de ​​lo contrario, omítelo. También para la tabla agrupada en PK, consulte la respuesta @JNK.