Respuesta.

Históricamente, las tareas de agregación y agrupación en SQL a menudo surgían para la generación de informes y análisis. Ya en las bases de datos relacionales de los años 80 aparecían funciones agregadas básicas (SUM, COUNT, AVG), pero con grandes volúmenes de datos, el clásico GROUP BY se ralentizaba. Surgió el problema de escalabilidad: las consultas con decenas de millones de registros y múltiples grupos bloqueaban tablas y ralentizaban el trabajo.

El problema radica en que, con un enfoque ineficiente, el servidor SQL consume muchos recursos en ordenaciones, tablas intermedias y lecturas desde disco. Es especialmente complicado cuando la agrupación se realiza por varias columnas o con un conjunto dinámico de datos a agregar.

La solución radica en construir correctamente índices en las columnas agrupadas, utilizar particionamiento, "semi-agregación" y optimizar la estructura de la consulta. Para las tareas de análisis empresarial, a menudo se utilizan expresiones de tabla comunes (CTE) estructuradas, vistas materializadas y funciones de ventana.

Ejemplo de código:

WITH PreAgg AS (
    SELECT customer_id, region, SUM(amount) AS total_amount
    FROM sales
    WHERE sale_date >= '2024-01-01'
    GROUP BY customer_id, region
)
SELECT region, COUNT(DISTINCT customer_id) AS customers, SUM(total_amount) AS region_amount
FROM PreAgg
GROUP BY region
ORDER BY region_amount DESC;

Características clave:

Los índices en columnas agrupadas aceleran radicalmente GROUP BY
Almacenar datos agregados previamente (resumen) reduce la carga
Las vistas materializadas simplifican y aceleran informes complejos

Preguntas trucos.

¿La rendimiento de GROUP BY depende del orden de las columnas en SELECT?

No, el orden de las columnas en SELECT no afecta la velocidad, solo es crítico por cuáles columnas se agrupan y si hay un índice sobre ellas.

¿Es obligatorio especificar una función de agregación para cada campo en SELECT al usar GROUP BY?

No es obligatorio, si el campo se incluye en GROUP BY, se puede seleccionar sin agregar. Si el campo no participa en la agrupación, debe agregarse obligatoriamente.

SELECT department, MIN(salary) FROM employees GROUP BY department;

¿Se puede anidar un GROUP BY dentro de otro para agregaciones multinivel?

Sí, los CTE anidados o subconsultas permiten hacer agregaciones "multicapas" con resultados intermedios.

WITH Step1 AS (
  SELECT customer, SUM(amount) AS cust_sum FROM orders GROUP BY customer
)
SELECT COUNT(*) FROM Step1 WHERE cust_sum > 10000;

Errores comunes y anti-patrones

GROUP BY en columnas no indexadas o en un gran número de campos
Uso descuidado de funciones de agregación (por ejemplo, valores NULL)
Agregación sin filtrado (no se descartan datos innecesarios)

Ejemplo de la vida real

Caso negativo

Un analista construye un informe con múltiples GROUP BY sobre una tabla de 200 millones de registros sin índices y sin particionar la consulta, toda la oficina "se cuelga" a las 9 de la mañana. La ejecución toma 40 minutos.

Pros:

No se necesita un diseño por etapas innecesario

Contras:

Carga catastrófica en el servidor, ralentizaciones, se bloquean todas las demás consultas

Caso positivo

Un ingeniero utiliza CTE para la filtración previa, índices adecuados en los campos necesarios y divide la agregación en varias etapas. El informe se genera en 5 segundos.