¿Cuáles son las trampas al usar la construcción GROUP BY en SQL, especialmente en la agregación y la optimización de consultas complejas?

Respuesta.

GROUP BY se utiliza para agrupar filas y agregar datos, pero si se aplica incorrectamente, puede causar errores graves o un funcionamiento subóptimo.

Puntos clave:

• En SELECT solo se permiten columnas de GROUP BY o funciones de agregado.
• En consultas complejas con múltiples JOINs, pueden ocurrir duplicados y agregaciones incorrectas.
• Orden formal: GROUP BY se ejecuta después de WHERE y antes de HAVING.
• Si no hay indexación en las columnas de grupo, la consulta puede funcionar muy lentamente con grandes volúmenes de datos.
• HAVING filtra ya después de la agrupación, mientras que WHERE lo hace antes.

Ejemplo:

SELECT customer_id, COUNT(*) as orders
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY customer_id
HAVING COUNT(*) > 10;

Pregunta engañosa.

¿Se pueden referir en SELECT después de GROUP BY a campos que no se mencionaron ni en GROUP BY ni en la función de agregado?

Respuesta: No, esto causará un error en la mayoría de las implementaciones de SQL (por ejemplo, en MS SQL, PostgreSQL). Algunas bases de datos específicas pueden mostrar un valor aleatorio e incorrecto (especialmente en MySQL cuando el sql_mode 'ONLY_FULL_GROUP_BY' está desactivado), pero este comportamiento es incorrecto y no está garantizado por el estándar. Ejemplo correcto:

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

Ejemplos de errores reales debido a la falta de conocimiento de los matices del tema.

---

Historia

En un proyecto de e-commerce, el informe "ingresos por productos" se preparó con la consulta SELECT sku, price, SUM(qty) FROM orders GROUP BY sku. No se tuvo en cuenta: price no se incluyó en GROUP BY ni estaba en una función de agregado, el resultado fue que MySQL devolvía el primer valor de precio que encontraba, lo que causó serios errores en el informe al estar en promoción. La solución fue agregar price en GROUP BY o usar una función de agregado.

---

Historia

En un proyecto de BI, un informe complejo con varios JOIN y GROUP BY se ejecutaba durante 80 minutos en lugar de los 3 planeados. Después del análisis se descubrió: faltaban índices sobre el campo de GROUP BY y filtrado, lo que creaba enormes tablas temporales para la agregación. La solución fue optimizar los índices y reescribir la consulta con expresiones de tabla.

---

Historia

Un desarrollador aplicó HAVING para filtrar valores por un atributo no agregado del usuario. Como resultado, el servidor realizó la agrupación sobre todos los datos y luego eliminó algunos a través de HAVING, reduciendo el rendimiento. Se corrigió moviendo esta verificación a WHERE, para restringir la selección antes de la agregación.