La lección anterior terminó con una lista de preguntas que no sabías responder todavía, y todas tenían la misma forma: comparar cada fila con el resultado de otra consulta. ¿Qué productos superan el precio medio del catálogo? ¿Qué clientes tienen un ticket medio por encima de la media general —la pregunta que 04-06 dejó explícitamente reservada para esta lección? ¿Qué pedidos incluyen el producto más caro?

La respuesta a todas ellas es la misma herramienta: una subconsulta, una consulta escrita entre paréntesis dentro de otra. Aquí aprenderás el vocabulario, los tres tipos de subconsulta según lo que devuelven, cómo se usan con IN, ANY y ALL, y los tres errores clásicos que producen desde un mensaje rojo hasta —mucho peor— un resultado vacío sin ningún aviso.

1. Qué es una subconsulta: vocabulario, correlación y tipos
2. Subconsulta escalar en el WHERE
3. La pregunta pendiente de 04-06: el ticket medio
4. Subconsultas de lista: IN, ANY/SOME y ALL
5. Los tres errores clásicos
6. Dónde puede aparecer una subconsulta
7. Errores Comunes y Consejos
8. Ejercicios
9. Conclusión

Una subconsulta (o consulta anidada) es una sentencia SELECT completa, escrita entre paréntesis, que aparece dentro de otra sentencia SQL. El motor la ejecuta y usa su resultado como si fuera un valor, una lista o una tabla.

La consulta que contiene a la otra es la consulta externa (outer query); la de dentro, la subconsulta (subquery). Una subconsulta puede contener otra, sin más límite que la legibilidad. Tres reglas de sintaxis sin excepción: los paréntesis son obligatorios; la subconsulta se escribe entera (SELECT, FROM, WHERE, GROUP BY… lo que necesite); y un ORDER BY dentro de una subconsulta casi nunca sirve de nada, salvo acompañado de un LIMIT.

Esta es la distinción que estructura el módulo entero, y conviene fijarla antes que ninguna otra.

La prueba práctica es infalible: selecciona la subconsulta, ejecútala sola y mira qué pasa. La primera devuelve 9.0350000000000000. La segunda da ERROR: missing FROM-clause entry for table "p", porque p no existe fuera de la consulta externa. Toda esta lección trata de las no correlacionadas.

La segunda clasificación, transversal a la anterior, se refiere a la forma del resultado, y determina dónde puede aparecer la subconsulta y con qué operadores se combina.

Las escalares y las de tabla cubren el 99 % del SQL que escribirás. Las de fila son elegantes pero raras: WHERE (precio, stock) = (SELECT MAX(precio), 40 FROM productos) devuelve una única fila, el matcha (22,00 € y 40 unidades).

Nota de dialecto: los constructores de fila (a, b) = (...) funcionan en PostgreSQL, MySQL y MariaDB; SQLite y SQL Server no los admiten y exigen dos condiciones unidas con AND.

El caso de uso más común de todos: comparar cada fila con un valor calculado sobre el conjunto. La pregunta es "¿qué productos están por encima del precio medio del catálogo?", y el intento ingenuo es este:

Es el mismo error de 04-06 y por la misma razón: cuando se ejecuta el WHERE (paso 2 del orden lógico) el motor mira una fila cada vez y no ha calculado ningún agregado. La subconsulta lo resuelve porque es otra consulta, con su propio recorrido completo por la tabla:

9 filas: 9 productos de 20 superan los 9,035 € de precio medio (SELECT ROUND(AVG(precio), 4) FROM productos → 9.0350, la cifra de 04-04). Lo importante es cómo se ejecuta: PostgreSQL evalúa la subconsulta una sola vez, obtiene 9.0350000000000000 y sustituye la expresión por ese número; a partir de ahí la consulta externa es un WHERE precio > 9.0350000000000000 corriente. No hay bucle: es una constante calculada al vuelo. Y ojo con un detalle que importa: la comparación se hace con el valor sin redondear — con otros datos, un céntimo decide si una fila entra o sale. Nunca redondees el valor de comparación; redondea solo lo que muestras.

En 04-06 calculaste el ticket medio de cada cliente y comprobaste que la media global de los 20 tickets es de 36,40 €, pero no pudiste unir las dos cosas: HAVING sabe comparar el agregado de un grupo con una constante o con otro agregado del mismo grupo, nunca con un agregado calculado sobre otro conjunto de filas. Una subconsulta escalar en el HAVING es la pieza que faltaba.

Primero, el valor de referencia. La media global no es la media de las 47 líneas (eso daría los 15,49 € de importe medio de línea), sino la media de los 20 tickets:

Y ahora la misma expresión, inyectada en el HAVING:

Tres clientes de doce, exactamente los que 04-06 anticipó. Paso a paso:

1. FROM + dos JOIN: se parte de las 47 líneas de detalle y se sube hasta el cliente; es la consulta canónica de detalle del curso. El GROUP BY forma 12 grupos, uno por cliente comprador (los clientes 13, 14 y 15 ya los descartó el INNER JOIN).
2. La subconsulta escalar se evalúa una vez y devuelve 36.39725, la media exacta sin redondear.
3. HAVING compara el ticket medio de cada grupo con esa constante y descarta nueve grupos.
4. SELECT proyecta y redondea. El redondeo es solo de presentación: la comparación ya se hizo con toda la precisión.

Y una lectura de negocio: los tres son clientes extranjeros, ninguno español supera la media (el más cercano es Lucía, con 35,87 €). Los portes a Portugal y Francia cuestan 9,90 € y 12,50 € frente a los 4,95 € nacionales, y el cliente compensa haciendo pedidos más grandes. Eso sí, dos de los tres tienen un solo pedido: el caso realmente sólido es Sofia, con dos tickets de 64,88 € y 47,00 €.

Por qué va en el HAVING y no en el WHERE: la condición compara un agregado del grupo con la constante, y el WHERE no puede usar agregados. La subconsulta solo aporta el número con el que comparar.

Cuando la subconsulta devuelve varias filas de una sola columna, la forma natural de usarla es IN. Ya conoces el operador de 04-02 con una lista escrita a mano; ahora la lista la calcula otra consulta.

(3 primeras de 12 filas: los clientes 1 a 12, los 12 compradores.) Aquí hay un detalle capital que retomaremos en 07-05: la subconsulta devuelve 20 valores (uno por pedido, con repeticiones), pero el resultado tiene 12 filas. IN no multiplica: pregunta si el valor está en la lista y responde sí o no una sola vez por fila externa. Un INNER JOIN con pedidos habría devuelto 20 filas.

Un segundo ejemplo, con una subconsulta agregada: productos de las categorías que tienen más de tres productos.

17 productos de 20. Las categorías con más de tres referencias son Alimentación (5), Cosmética natural (4), Hogar sostenible (4) y Bebidas (4); quedan fuera Higiene personal (productos 18 y 19) y Complementos (el 20). La subconsulta es una consulta agregada completa, con su GROUP BY y su HAVING: puedes calcular un conjunto de claves con toda la maquinaria del módulo 4 y usarlo como filtro.

La equivalencia con = ANY. El estándar define IN como azúcar sintáctico de = ANY: c.id IN (sub) y c.id = ANY (sub) producen el mismo plan y el mismo resultado. IN se lee mejor y es lo que verás en el código real; = ANY importa porque explica la familia entera:

SOME es un sinónimo exacto de ANY que nadie usa. La forma que de verdad aparece es > ALL, y su pregunta natural es "más caro que cualquiera de los de aquella categoría":

5 productos cuestan más que todos los de Alimentación, cuyo tope es el aceite de oliva (12,50 €). La escritura > (SELECT MAX(precio) FROM productos WHERE categoria_id = 1) devuelve lo mismo y se lee mejor. Con ANY en lugar de ALL la condición sería "más caro que el más barato de Alimentación" (1,95 €) y saldrían 19 productos.

Cuidado con los conjuntos vacíos. Si la subconsulta no devuelve ninguna fila, > ALL es verdadero para todas (no hay contraejemplo) y > ANY es falso para todas (no hay caso favorable). Impecable en lógica y desconcertante en la práctica: precio > ALL (SELECT precio FROM productos WHERE categoria_id = 99) devuelve los 20 productos.

Alimentación tiene cinco productos, la subconsulta devuelve cinco precios y > no sabe con cuál comparar. Los arreglos son tres y cada uno responde a una pregunta distinta: > (SELECT MAX(precio) ...) y > ALL (...) dicen "más caro que el más caro"; > ANY (...) dice "más caro que alguno". Es el menos peligroso de los tres porque es ruidoso, y es un error de datos, no de sintaxis: la misma consulta funcionaría si la categoría tuviera un solo producto y reventaría al dar de alta el segundo. Si la subconsulta devuelve varias columnas, el mensaje es ERROR: subquery must return only one column.

Ningún mensaje, ninguna advertencia. La categoría 99 no existe, la subconsulta no encuentra filas, AVG sobre un conjunto vacío devuelve NULL (04-04) y precio > NULL se evalúa a UNKNOWN para las veinte filas. Como el WHERE solo deja pasar lo que es TRUE (04-03), el resultado se vacía en silencio. Este es el más peligroso de los tres, porque un informe vacío parece un informe legítimo: "este mes no hubo ninguno". Cómo defenderse: ejecuta siempre la subconsulta sola antes de anidarla; envuélvela en COALESCE cuando exista un valor por defecto sensato (> COALESCE((SELECT AVG(...)...), 0), 06-04); y si la pregunta es de existencia, usa EXISTS, que nunca devuelve NULL (07-03).

En 04-02 lo llamaste "el error más caro de SQL". Con subconsultas es mucho más fácil de cometer, porque ya no ves la lista: la calcula otra consulta y no sabes si trae nulos.

Y sin embargo sabes que hay cinco empleados sin pedidos: solo el 4, el 5 y el 6 aparecen en pedidos. Lo que ha pasado es que la subconsulta devuelve {4, 5, 6, NULL} — los 10 pedidos web tienen empleado_id a NULL. Para el empleado 1:

Lo mismo para las ocho filas. Con un solo NULL en la lista, NOT IN no puede devolver TRUE jamás. Los tres arreglos —filtrar los nulos dentro, NOT EXISTS (07-03) y el anti-join de 03-03— son estos:

Los tres devuelven lo mismo:

5 filas. Y hay una asimetría que sorprende a todo el mundo: IN sí funciona con nulos. 4 IN (4, 5, 6, NULL) es TRUE, porque basta con que una comparación acierte. El problema es exclusivo de la negación. La comparación de las cuatro formas de responder "qué no casa" llega en 07-03, y su tabla definitiva, en 07-05.

Casi en cualquier sitio donde quepa un valor o una tabla:

Dos ejemplos del módulo 5 revisitados, ahora que sabes cómo se llaman: UPDATE productos SET precio = ROUND(precio * 1.05, 2) WHERE id NOT IN (SELECT producto_id FROM lineas_pedido) sube un 5 % lo que nunca se ha vendido, y DELETE FROM resenas WHERE cliente_id NOT IN (SELECT id FROM clientes) limpia reseñas huérfanas. Los dos son seguros porque lineas_pedido.producto_id y clientes.id son NOT NULL. Si alguna admitiera nulos, el UPDATE no modificaría nada y el DELETE no borraría nada — la trampa de 5.3, ahora con consecuencias sobre los datos. Y dónde no puede aparecer una subconsulta: en el GROUP BY, ni —en PostgreSQL— dentro de una restricción CHECK.

• Escribir un agregado en el WHERE. aggregate functions are not allowed in WHERE. Lo que necesitas es una subconsulta escalar.
• Usar una subconsulta multifila donde se espera un valor. more than one row returned by a subquery used as an expression. Añade un agregado, un ORDER BY ... LIMIT 1, o cambia a IN/ANY/ALL.
• No comprobar que la escalar devuelve algo. Si devuelve cero filas vale NULL, el filtro se vacía en silencio y el informe parece correcto. Es el error más caro de la lección.
• NOT IN sobre una columna que admite nulos. Cero filas, siempre. Usa NOT EXISTS o filtra los nulos dentro de la subconsulta.
• Redondear el valor de comparación. > ROUND(AVG(precio), 2) no es > AVG(precio). Redondea al mostrar, no al comparar. Y evita el ORDER BY dentro de una subconsulta de lista: no aporta nada y cuesta tiempo.
• Consejo: ejecuta siempre la subconsulta sola primero. Es la técnica de depuración número uno del módulo; si no se puede ejecutar sola, es correlacionada.
• Consejo: si necesitas columnas de la otra tabla en el resultado, no es una subconsulta: es un JOIN. La subconsulta filtra y calcula; no aporta columnas al SELECT externo (07-05).

Marketing quiere una lista de productos caros medidos con una vara concreta: los que superan la media de precios de la categoría Cosmética natural. Muestra id, nombre, categoría y precio, ordenados por precio descendente, y no escribas el umbral a mano. Después responde: ¿cuántos de los productos que salen son de Cosmética natural, y por qué los otros dos de esa categoría no aparecen?

Un compañero quiere saber qué clientes nunca han escrito una reseña y ha escrito esto:

1. ¿Funciona? Justifica la respuesta mirando el esquema de 01-06, sin ejecutarla.
2. Da el resultado y di cuántos de esos clientes sí han comprado alguna vez.
3. Reescríbela con NOT EXISTS y con un anti-join, y explica por qué aquí las tres son equivalentes.

Dirección pregunta: "¿qué pedidos incluyen el producto más caro del catálogo?". Escribe una única consulta que devuelva id del pedido, fecha, cliente y estado, sin escribir a mano ni el nombre ni el id de ese producto. (Pista: necesitarás dos subconsultas, una dentro de otra.) Indica después qué pasaría si hubiera dos productos empatados en el precio máximo.

Solución 1

6 filas. El umbral calculado es 11,5375 € (46,15 € entre 4 productos). Solo dos son de Cosmética natural, la crema de aloe y el aceite corporal; los otros dos de la categoría —champú 8,40 € y bálsamo 4,60 €— quedan por debajo de su propia media, que está tirada hacia arriba precisamente por los dos caros.

El punto de fondo: el umbral sale de una categoría pero se aplica a todo el catálogo, porque una subconsulta no correlacionada se evalúa una vez y vale igual para las veinte filas. Comparar cada producto con la media de su propia categoría exige una correlacionada: lección siguiente.

Solución 2

1. Sí funciona, y se sabe sin ejecutarla: resenas.cliente_id está declarada NOT NULL (01-06, tabla 3.8), así que la subconsulta no puede devolver ningún NULL y NOT IN se comporta correctamente. La sospecha era el reflejo correcto ante cualquier NOT IN; el esquema la despeja. 2. El resultado:

6 clientes de 15, y tres de ellos sí han comprado: Ana (2 pedidos), Julien (1) y Diego (1). Los otros tres son los conocidos 13, 14 y 15, que no han comprado nunca y por tanto no podían reseñar nada. Distinguir ambos grupos importa: a Ana, Julien y Diego se les puede pedir una opinión; a Núria, Hugo e Inés hay que venderles algo primero.

3. Las dos reescrituras, con el mismo resultado de seis filas:

Las tres son equivalentes aquí por una única razón: resenas.cliente_id es NOT NULL. Si mañana se permitieran reseñas anónimas con cliente_id nulo, la versión con NOT IN pasaría a devolver cero filas y las otras dos seguirían funcionando. La equivalencia depende del esquema, no de la sintaxis.

Solución 3

3 pedidos. El producto más caro es el Té verde matcha ceremonial 30 g (22,00 €) y se ha vendido tres veces. Hay dos niveles: la subconsulta interna devuelve un valor escalar (el id del producto más caro) y la intermedia, una lista de pedido_id.

Si hubiera empate, la interna seguiría devolviendo una sola fila —LIMIT 1 corta arbitrariamente— y perderías en silencio los pedidos del otro producto. La versión robusta cambia el = por un IN y elimina el LIMIT: WHERE lp.producto_id IN (SELECT id FROM productos WHERE precio = (SELECT MAX(precio) FROM productos)). Con los datos actuales devuelve lo mismo, pero no se rompe el día que alguien dé de alta un segundo producto de 22,00 €. ORDER BY ... LIMIT 1 dentro de una subconsulta es cómodo y frágil.

Has abierto la puerta del módulo:

• Una subconsulta es una consulta entre paréntesis dentro de otra; la que la contiene es la consulta externa. Según lo que devuelven hay tres tipos —escalar, de fila y de tabla—, y cada uno admite unos operadores distintos.
• La distinción que organiza el módulo es no correlacionada (no menciona nada de fuera, se ejecuta sola, se evalúa una vez) frente a correlacionada (usa un alias externo, no se puede ejecutar aislada, se evalúa una vez por fila).
• Una escalar en el WHERE resuelve "por encima de la media": 9 de los 20 productos superan los 9,035 € del catálogo. Y una escalar en el HAVING cierra la pregunta que 04-06 dejó pendiente: Julien, Sofia y Tiago son los únicos con un ticket medio superior a los 36,40 € de media global.
• IN (SELECT ...) filtra por una lista calculada —12 clientes compradores, 17 productos de categorías con más de tres referencias— y equivale a = ANY; > ALL compara con el máximo y > ANY con el mínimo. Y conoces los tres errores clásicos: la escalar con varias filas (ruidosa), la escalar con cero filas (silenciosa: da NULL y vacía el resultado) y NOT IN con nulos (cero filas garantizadas).

Todas las subconsultas de esta lección tienen algo en común: se calculan una vez y valen lo mismo para todas las filas. Por eso ninguna ha podido responder a "qué productos superan la media de su categoría": ese umbral es distinto para cada fila. En la lección siguiente, subconsultas correlacionadas, la subconsulta empezará a mirar hacia fuera —a la fila que la consulta externa está examinando en ese momento— y se ejecutará una vez por cada una de ellas. Cambia el modelo mental, cambia el coste y aparece toda una familia de preguntas nuevas.