Eu tenho uma tabela listada abaixo no SQL Server 2012. Há um índice clusterizado em RequisitionID – mas esta coluna não é exclusiva. Pode haver muitos ProductID para um RequisitionID.
CREATE TABLE [dbo].[RequisitionProducts](
[RequisitionID] [int] NOT NULL,
[ProductID] [int] NOT NULL,
[Qty] [int] NOT NULL,
[VendorID] [int] NOT NULL,
[UnitAmount] [decimal](10, 2) NOT NULL,
CONSTRAINT [pk_RequisitionProducts] PRIMARY KEY NONCLUSTERED
(
[RequisitionID] ASC,
[ProductID] ASC
)
)
CREATE CLUSTERED INDEX [cidx_RequistionProducts] ON [dbo].[RequisitionProducts]
(
[RequisitionID] ASC
)
GO
Pesquisei bastante e descobri que o Clustered Index pode ser não exclusivo - mas apenas em um cenário limitado. O único cenário mencionado apropriado é quando há uma pesquisa de intervalo . No meu caso, quase todas as consultas serão baseadas apenas em RequisitionID - e não há necessidade de pesquisa de intervalo.
Devo adicionar ProductID também para tornar o índice clusterizado exclusivo? Quais são os prós e contras?
Em vez disso , você deve excluir
cidx_RequistionProductse tornar a chave primária agrupada. O índice criado para oferecer suporte à chave primária fará o trabalho para você ao filtrarRequisitionID.Não vejo nenhum benefício em ter dois índices quando um é suficiente para fazer o trabalho. A remoção do índice extra economizará espaço em disco e custo de E/S ao atualizar a tabela.
Obrigado pelo comentário sobre
uniquifier.O SQL Server adiciona internamente um unificador para tornar o índice clusterizado exclusivo, se não for assim. Portanto, é melhor adicionar ProductID (que é int) ao índice clusterizado. Os comandos DBCC para testar isso estão presentes em Compreendendo e examinando o unificador no SQL Server - Ken Simmons .
O cenário de uso desta tabela é que ela possui inserções frequentes. Portanto, apresentarei uma chave substituta (coluna de identidade) e a tornarei uma chave primária e um índice clusterizado. Chave de agrupamento cada vez maior – o Debate do Índice Agrupado……….novamente!