El orden de ejecución de una consulta

En resumen: Una consulta SQL se escribe empezando por SELECT, pero la base la ejecuta en el orden FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT.

Problema

Aquí funciona, allí no

En la lección de los grupos, ORDER BY month usó el alias de SELECT. En la lección de HAVING repetimos todo el SUM(...), y SUM en WHERE dio un error. ¿Por qué un alias funciona en un sitio y en otro no?

La respuesta está en el orden en que la base lee la consulta. No es el orden en que tú la escribes.

La idea

Se escribe en un orden, se ejecuta en otro

Tú escribes así:

SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT

La base piensa así:

1. FROM: de dónde vienen las filas;
2. WHERE: qué filas se quedan;
3. GROUP BY: los grupos;
4. HAVING: qué grupos se quedan;
5. SELECT: qué se muestra y cómo se llama;
6. ORDER BY: el orden;
7. LIMIT: cuántas filas.

Este es el orden lógico de ejecución de una consulta. Los tres meses con más movimiento, sin los pedidos cancelados:

SQLbase de datos: tienda

SELECT strftime('%Y-%m', ordered_at) AS month, COUNT(*) AS orders
FROM orders
WHERE status <> 'cancelled'
GROUP BY strftime('%Y-%m', ordered_at)
HAVING COUNT(*) >= 5
ORDER BY orders DESC, month
LIMIT 3;

SELECT strftime('%Y-%m', ordered_at) AS month, COUNT(*) AS orders FROM orders WHERE status <> 'cancelled' GROUP BY strftime('%Y-%m', ordered_at) HAVING COUNT(*) >= 5 ORDER BY orders DESC, month LIMIT 3;

▶ EjecutarRestaurar la consultaBase nueva

Paso a paso: FROM toma los 60 pedidos. WHERE quita los 7 cancelados y quedan 53. GROUP BY los divide en 14 meses. HAVING conserva los seis con al menos 5 pedidos. SELECT calcula el mes y la cuenta y les pone nombre. ORDER BY los ordena, y LIMIT toma los tres primeros.

Más precisamente, para curiosos

Este es el orden en que la consulta debe parecer que se ejecuta. El plan real puede ser distinto: la base puede usar un índice o saltarse un paso, siempre que el resultado sea el mismo. Los planes de consulta los veremos en el módulo de índices.

La idea

Por qué el alias funciona en ORDER BY

El alias nace en SELECT, en el paso 5. ORDER BY es el paso 6, así que el nombre ya existe:

SQLbase de datos: tienda

SELECT order_id, SUM(quantity * unit_price) AS total
FROM order_items
GROUP BY order_id
ORDER BY total DESC
LIMIT 3;

SELECT order_id, SUM(quantity * unit_price) AS total FROM order_items GROUP BY order_id ORDER BY total DESC LIMIT 3;

▶ EjecutarRestaurar la consultaBase nueva

Los tres pedidos más grandes. Esto funciona en todas las bases. En WHERE, GROUP BY y HAVING, según la regla, el alias todavía no existe, porque van antes que SELECT.

Pruébalo

Los clientes más activos

Muestra los cinco clientes con más pedidos: customer_id y la cantidad en una columna llamada orders, el que más primero. En caso de empate va primero el customer_id menor.

SQLbase de datos: tienda

Comprobar▶ Ejecutar

Míralo

Lo que SQLite perdona

Según la regla, un alias en WHERE no debería funcionar. Los productos que con un 20 % de descuento cuestan menos de 1 €:

SQLbase de datos: tienda

SELECT name, price * 0.8 AS sale
FROM products
WHERE sale < 1;

SELECT name, price * 0.8 AS sale FROM products WHERE sale < 1;

▶ EjecutarRestaurar la consultaBase nueva

SQLite lo acepta. También acepta un alias en GROUP BY:

SQLbase de datos: tienda

SELECT strftime('%Y', ordered_at) AS year, COUNT(*)
FROM orders
GROUP BY year;

SELECT strftime('%Y', ordered_at) AS year, COUNT(*) FROM orders GROUP BY year;

▶ EjecutarRestaurar la consultaBase nueva

Otras bases no son tan permisivas. PostgreSQL acepta un alias en GROUP BY, pero no en WHERE: allí dice que la columna sale no existe. SQL Server no lo acepta ni en WHERE ni en GROUP BY.

La permisividad de SQLite tiene límites. Si el alias se llama igual que una columna, WHERE toma la columna:

SQLbase de datos: tienda

SELECT name, price * 0.8 AS price
FROM products
WHERE price < 1;

SELECT name, price * 0.8 AS price FROM products WHERE price < 1;

▶ EjecutarRestaurar la consultaBase nueva

Salen dos productos, no cuatro: WHERE price < 1 mira el precio real, no el rebajado. Y un alias de una agregación en WHERE sigue siendo «misuse of aggregate», porque en el paso 2 todavía no hay grupos:

SQLbase de datos: tienda

SELECT order_id, SUM(quantity * unit_price) AS total
FROM order_items
WHERE total > 30
GROUP BY order_id;

SELECT order_id, SUM(quantity * unit_price) AS total FROM order_items WHERE total > 30 GROUP BY order_id;

▶ EjecutarRestaurar la consultaBase nueva

Una consulta que funciona en todas partes: en WHERE repite la expresión (WHERE price * 0.8 < 1), y usa los alias con libertad en ORDER BY.

Ejercicio

El informe mensual

La dueña quiere un informe de 2026: para cada mes, cuántos pedidos hay (sin los cancelados) y de cuántos clientes distintos. Los meses con menos de 3 pedidos son demasiado tranquilos y no los necesita.

Muestra las columnas month (año-mes), orders y customers de los meses de 2026 con al menos 3 pedidos, sin contar los cancelados, en el orden de los meses.

SQLbase de datos: tienda

Comprobar▶ Ejecutar

Test

Ponte a prueba

1. ¿Por qué parte empieza la base cuando ejecuta la consulta?

FROMWHERESELECT

2. ¿Por qué funciona ORDER BY total cuando total es un alias de SELECT?

Solo funciona en SQLitePorque ORDER BY va después de SELECT y el nombre ya existePorque total es una columna de la tabla

3. ¿Qué es cierto de WHERE sale < 1, cuando sale es un alias de SELECT?

Funciona en todas partesNinguna base lo aceptaSQLite lo acepta, PostgreSQL da un error

4. La consulta tiene ORDER BY orders DESC y LIMIT 3. ¿Cuándo se toman las tres filas?

Después de ordenar, justo al finalAntes de ordenarAntes de HAVING

Comprobar

Empezar la lección de nuevo

Lecciones relacionadas

• Se basa en: Funciones de fecha · Funciones de agregación: COUNT, SUM, AVG · GROUP BY: un informe por grupos · HAVING: una condición para los grupos
• Continúa en: Funciones de ventana · La panadería, etapa 3: las preguntas
• Ejercicios sobre el tema: Resumir