Eu concordo com o Cade Roux .
Este artigo deve colocá-lo no caminho certo:
Uma coisa a observar, os índices clusterizados devem ter uma chave exclusiva (uma coluna de identidade que eu recomendaria) como a primeira coluna. Basicamente, ajuda seus dados a serem inseridos no final do índice e não causa muitas E / S de disco e divisões de página.
Em segundo lugar, se você estiver criando outros índices nos seus dados e eles forem construídos de maneira inteligente, eles serão reutilizados.
Por exemplo, imagine que você pesquise uma tabela em três colunas
estado, município, zip.
- você às vezes pesquisa apenas por estado.
- você às vezes pesquisa por estado e município.
- você pesquisa frequentemente por estado, município, CEP.
Em seguida, um índice com estado, município, zip. será usado nas três pesquisas.
Se você pesquisar sozinho apenas por zip, o índice acima não será usado (pelo SQL Server de qualquer maneira), pois zip é a terceira parte desse índice e o otimizador de consultas não considerará esse índice útil.
Você poderia criar um índice apenas no Zip que seria usado nesta instância.
A propósito: Podemos tirar vantagem do fato de que, com a indexação de várias colunas, a primeira coluna de índice é sempre utilizável para pesquisa e, quando você pesquisa apenas por 'estado', é eficiente, mas ainda não tão eficiente quanto o índice de coluna única no estado ' "
Eu acho que a resposta que você está procurando é que depende das cláusulas where das suas consultas usadas com freqüência e também do seu grupo por.
O artigo vai ajudar muito. :-)