Estoy de acuerdo con Cade Roux.
Este artículo debería llevarlo por el camino correcto:
- Índices en SQL Server 2005/2008:mejores prácticas, parte 1
- Índices en SQL Server 2005/2008 - Parte 2 - Internos
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 causan muchas divisiones de página y E/S de disco.
En segundo lugar, si está creando otros índices en sus datos y se construyen inteligentemente, se reutilizarán.
p.ej. imagina que buscas en una tabla en tres columnas
estado, condado, código postal.
- a veces busca solo por estado.
- a veces busca por estado y condado.
- usted 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 por zip, entonces el índice anterior no se utilizará (por SQL Server de todos modos) 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 este caso.
Por cierto, podemos aprovechar el hecho de que con la indexación de columnas múltiples, la primera columna del índice siempre se puede usar para buscar y cuando 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 su agrupación.
El artículo ayudará mucho. :-)
