No SQL Server, suponha que eu tenha uma tabela muito grande (colunas de A a Z) que tenha uma CHAVE PRIMÁRIA CLUSTERED em A e um índice IX1 NÃOCLUSUÍDO UNIQUE sobre as colunas B, C, D incluem E, F, G. Em seguida, preciso cobrir outra consulta com um novo índice NONCLUSTERED IX2 sobre D, C e B, incluindo J, K, M.
Com o IX1 já aplicando a exclusividade em B, C, D, faz sentido criar IX2 UNIQUE também? Existem alguns prós e contras sérios.
Se o seu índice é único, diga ao SQL que é único. O otimizador pode usar as informações adicionais, não há desvantagem em fazer isso.
Dito isso, você realmente precisa de um segundo índice? A ordem diferente das chaves para algumas outras consultas é usada? Se não, por que não apenas adicionar as colunas de inclusão adicionais ao primeiro índice, provavelmente será mais barato a longo prazo.
Não tenho certeza de como o cenário específico iria se desenrolar, mas você deve ser capaz de testá-lo sem muita dificuldade.
No ambiente de desenvolvimento (se existir) tente executar consultas com ambos os cenários e confira os planos de execução. Se o segundo índice estiver impedindo coisas como varreduras de tabela, há uma boa chance de que valha a pena. Se você achar que o primeiro índice está realmente fazendo todo o trabalho, provavelmente não é.
Eu não vejo grandes contras fora das coisas usuais quando se trata de índices. Se você começar a adicionar muitas inserções, atualizações e exclusões, poderá começar a diminuir a velocidade e também ocupará mais espaço em disco.