Orden de campo en un orden de índice compuesto con campos de alta selectividad y baja selectividad

Tengo una tabla de SQL Server con más de 3 mil millones de filas. Una de mis consultas lleva mucho tiempo, así que estoy considerando optimizarla. La consulta se ve así:

SELECT [Enroll_Date]
      ,Count(*) AS [Record #]
      ,Count(Distinct UserID) AS [User #]
  FROM UserTable
  GROUP BY [Enroll_Date]

[Enroll_Date] es una columna de baja selectividad con menos de 50 valores posibles, mientras que la columna UserID es una columna de alta selectividad con más de 200 millones de valores distintos. Basado en mi investigación, creo que debería crear un índice compuesto no agrupado en estas dos columnas, y en teoría la columna de alta selectividad debería ser la primera columna. Pero no estoy seguro en mi caso, ¿funcionaría porque estoy usando la columna de baja selectividad en el grupo por cláusula?

Esta tabla no tiene índice agrupado.

Como alternativa a la solución de @ AaronBertrand (si no puede o no desea crear una vista indizada), le recomendaría que cree un índice en (Enroll_Date, UserID). Si este tipo de pregunta es muy común en su tabla, probablemente este debería ser su índice agrupado.

En general, no recomendaría índices de alta selectividad como una "mejor práctica" general, sino que mire qué índice le dará a su consulta el mejor rendimiento.

Un índice activado (Enroll_Date, UserID)le dará a su consulta un plan de consulta altamente optimizado y sin bloqueo con Stream Aggregates.

"Sin bloqueo" en este contexto significa que la consulta no necesita almacenar cantidades significativas de datos (como, por ejemplo, una ordenación o un agregado hash lo haría), lo que significa que (a) comienza a devolver filas inmediatamente, y ( b) prácticamente no consume memoria de trabajo.

La respuesta de Aarons es una gran solución. Contestaré la pregunta asumiendo que no quieres tomar ese enfoque.

La consulta que publicaste generalmente se ejecutará primero agrupando (Enroll_Date, UserID)y luego nuevamente (Enroll_Date). Esta optimización es nueva para SQL Server 2012. Tiene efecto en caso de una sola COUNT DISTINCT.

Un índice en esas dos columnas en el orden específico (Enroll_Date, UserID)será suficiente para obtener un plan eficiente que canalice una exploración de índice en dos agregados de flujo consecutivos. El orden opuesto no permitiría ese plan.

Por lo tanto, use la orden (Enroll_Date, UserID). No tienes elección aquí.

Suena como un escenario ideal para una vista indizada, que le permite pagar los cálculos y los agregados en el momento de la escritura en lugar del tiempo de consulta.

CREATE VIEW dbo.MyIndexedView
WITH SCHEMABINDING
AS 
  SELECT Enroll_Date, UserID, RawCount = COUNT_BIG(*)
  FROM dbo.UserTable
  GROUP BY Enroll_Date, UserID;
GO

CREATE UNIQUE CLUSTERED INDEX CIX_miv ON dbo.MyIndexedView(Enroll_Date, UserID);

Eso tomará un tiempo en crearse y, por supuesto, requerirá mantenimiento en todas las operaciones DML, al igual que un índice en la tabla base.

Ahora, la consulta en esta vista sería bastante similar: cada fila de la vista ahora representa un combo de usuario / fecha distinto, por lo que esa cifra se puede calcular con un solo COUNT (*), mientras que el número total de filas en la tabla base es ya está parcialmente agregado para usted, ahora solo necesita agregarlos usando SUMA por fecha:

SELECT Enroll_Date, 
  [Record #] = SUM(RawCount),
  [User #] = COUNT(*)
FROM dbo.MyIndexedView WITH (NOEXPAND)
GROUP BY Enroll_Date; 

Sugerencia NOEXPAND agregada, después de recordar esto y esto .

Puedo decirle sin lugar a dudas que esta consulta será más rápida que su consulta actual (pero no por cuánto), excepto en el raro caso en que tenga exactamente un usuario para cada fecha (en cuyo caso la misma cantidad de datos tendrá para leer) y las columnas que conocemos son las únicas columnas en el índice de la tabla base. Si ese aumento de rendimiento en el momento de la lectura vale la pena el trabajo extra que afectará la parte de escritura de su carga de trabajo es algo que no podemos decirle: tendrá que probarlo para medir la compensación (no hay índice libre).

Y si usa con frecuencia las mismas cláusulas WHERE comunes contra Enroll_Date para rangos específicos y bien definidos (por ejemplo, el trimestre actual o el año hasta la fecha), podría agregar índices filtrados coincidentes que reduzcan aún más esa E / S (pero siempre hay un compensación).

También puede considerar poner un índice agrupado en la tabla base. Este no parece ser uno de esos casos de uso muy raros que se benefician de un montón.