Estoy de acuerdo con Cade Roux .
Este artículo debería llevarte por el camino correcto:
Una cosa a tener en cuenta, los índices agrupados deben tener una clave única (una columna de identidad que recomendaría) como la primera columna. Básicamente, ayuda a que sus datos se inserten al final del índice y no causa muchas E / S de disco y divisiones de página.
En segundo lugar, si está creando otros índices en sus datos y se construyen de manera inteligente, se reutilizarán.
por ejemplo, imagina que buscas una tabla en tres columnas
estado, condado, código postal
- a veces buscas solo por estado.
- a veces busca por estado y condado.
- busca con frecuencia por estado, condado, código postal.
Luego un índice con estado, condado, código postal. se usará en las tres búsquedas.
Si busca bastante solo con zip, entonces el índice anterior no se utilizará (de todos modos, SQL Server) ya que zip es la tercera parte de ese índice y el optimizador de consultas no verá ese índice como útil.
Luego, podría crear un índice solo en Zip que se usaría en esta instancia.
Por cierto , podemos aprovechar el hecho de que con la indexación de varias columnas, la primera columna de índice siempre se puede usar para buscar y cuando se busca solo por 'estado' es eficiente pero no tan eficiente como el índice de una sola columna en estado '
Supongo que la respuesta que está buscando es que depende de sus cláusulas where de sus consultas de uso frecuente y también de los by by de su grupo.
El artículo ayudará mucho. :-)