Indices en las columnas ORDER-BY/GROUP-BY/DISTINCT

 Las sentencias ORDER-BY, GROUP-BY y DISTINCT son todas tipos de ordenación. El procesador de consultas de SQL Server implementa la ordenación de dos modos distintos.

Si los registros ya están ordenados por un índice, el procesador sólo tiene que usar el índice. De lo contrario, el procesador debe utilizar una tabla de trabajo temporal para ordenar primero los registros.
 
Esta ordenación preliminar puede provocar retrasos iniciales considerables en dispositivos con una Procesador lento y memoria limitada, y debería evitarse esto si el tiempo porque el tiempod e respuesta es fundamental.
En el contexto de índice con varias columnas, para que ORDER-BY o GROUP-BY tengan en cuenta un índice concreto, las columnas ORDER-BY o GROUP-BY deben coincidir con el conjunto de prefijos de columnas de índice en el orden exacto.
Por ejemplo, el índice CREATE INDEX NombreEmpleado ON Empleados («Apellidos» ASC, «Nombres» ASC) puede ayudar a optimizar las siguientes consultas:

– SELECT …….. ORDER BY / GROUP BY » Apellidos » …
– SELECT …….. ORDER BY / GROUP BY » Apellidos «, «Nombres» …

No ayudará a optimizar:

– SELECT …….. ORDER BY / GROUP BY «Apellidos» …
– SELECT …….. ORDER BY / GROUP BY «Apellidos», «Nombres» …

Para que una operación DISTINCT tenga en cuenta un índice de varias columnas, la lista de proyección debe coincidir con todas las columnas de índice, aunque no es necesario que estén en el orden exacto. El índice anterior puede ayudar a optimizar las siguientes consultas:

– SELECT …….. DISTINCT «Apellidos», «Nombres» …
– SELECT …….. DISTINCT «Nombres», «Apellidos» …

No ayudará a optimizar:

– SELECT …….. DISTINCT «Apellidos» …
– SELECT …….. DISTINCT «Nombres» …

Si la consulta siempre devuelve filas únicas, no especifique la palabra clave DISTINCT, ya que sólo aumenta la sobrecarga.
Hay que tener en cuenta que cada vez que ponemos agrupaciones del tipo ORDER-BY, GROUP-BY y DISTINCT, podemos estar penalizando el rendimiento si no tenemos los índices adecuados y muchas veces estas agrupaciones que usamos no tienen sentido ya que se pueden hacer desde el reporte o la aplicación.

En ocasiones es mejor no dar una sobrecarga el motor, ya que he visto como quedan resuelto algunos temas de performance en querys simplemente por eliminar estas agrupaciones, recordemos que las agrupaciones las podemos hacer muchas veces en la parte cliente de nuestra aplicación sin castigar al motor de base innecesariamente.