SQL Subqueries: Ejemplos Completos 2026 🔍

Dominar SQL subqueries ejemplos es esencial para cualquier desarrollador backend, analista de datos, ingeniero de bases de datos o data scientist que trabaja con bases de datos relacionales (PostgreSQL, MySQL, SQL Server, Oracle), ya que las subqueries o subconsultas (consultas SQL anidadas dentro de otras consultas) son la herramienta fundamental para resolver problemas complejos de filtrado, agregaciones anidadas, comparaciones dinámicas y análisis multitabla que serían imposibles o extremadamente complicados con queries simples. Una subquery es una consulta SELECT completa encerrada entre paréntesis que se ejecuta dentro de otra consulta (query externa u outer query), retornando resultados temporales que la query externa utiliza en cláusulas WHERE, SELECT, FROM, HAVING o JOIN para refinar filtrado, calcular valores derivados, crear tablas temporales virtuales o verificar existencia de registros relacionados.

Esta guía exhaustiva de SQL subqueries ejemplos cubre definiciones técnicas precisas de subqueries escalares (retornan valor único), subqueries de fila única, subqueries de múltiples filas/columnas, subqueries correlacionadas vs no-correlacionadas con diferencias críticas de ejecución, posicionamiento estratégico en WHERE (filtrado dinámico con IN/NOT IN/ANY/ALL/EXISTS), SELECT (columnas calculadas), FROM (derived tables/inline views), HAVING (filtros agregados), ejemplos código completos funcionales PostgreSQL/MySQL con casos uso reales (empleados salario > promedio, productos vendidos, clientes con órdenes, rankings top N, detección duplicados), optimización performance (cuándo usar JOIN vs subquery, índices apropiados, CTEs Common Table Expressions como alternativa readable), límites anidamiento (hasta 32 niveles teóricamente pero 3-4 recomendado readability), y mejores prácticas 2026 incluyendo cuándo evitar subqueries correlacionadas caras, simplificación con WITH clauses, explain plans análisis ejecución.

📖 Qué Son SQL Subqueries: Definición Técnica

Antes de explorar SQL subqueries ejemplos detallados, es fundamental entender la definición precisa y contexto donde subqueries se utilizan en SQL moderno.

Una subquery (subconsulta o consulta anidada) es una consulta SELECT completa que se anida dentro de otra instrucción SQL (SELECT, INSERT, UPDATE, DELETE). La subquery se encierra SIEMPRE entre paréntesis y su resultado es utilizado por la query principal (outer query o consulta externa) como parte de una condición WHERE, un valor en SELECT, una tabla en FROM, o un filtro en HAVING.

🎯 Sintaxis General SQL Subqueries

-- Subquery en WHERE (filtrado)
SELECT column1, column2
FROM table_name
WHERE column1 OPERATOR (
    SELECT column1 
    FROM another_table 
    WHERE condition
);

-- Subquery en SELECT (columna calculada)
SELECT 
    column1,
    (SELECT AVG(salary) FROM employees) AS avg_salary
FROM table_name;

-- Subquery en FROM (tabla derivada)
SELECT alias.column1, alias.column2
FROM (
    SELECT column1, column2 
    FROM table_name 
    WHERE condition
) AS alias;

📊 Tipos de Subqueries por Resultado Retornado

1. Subqueries Escalares (Scalar Subqueries):

• 📌 Definición: Retornan exactamente UN valor (1 fila, 1 columna)
• 🔧 Uso: Comparaciones con =, >, <, >=, <=, !=
• ✅ Ejemplo: (SELECT AVG(salary) FROM employees) retorna número único

2. Subqueries de Fila Única (Single-Row Subqueries):

• 📌 Definición: Retornan 1 fila con múltiples columnas
• 🔧 Uso: Comparaciones tupla-a-tupla
• ✅ Ejemplo: (SELECT salary, department FROM employees WHERE id = 123)

3. Subqueries de Múltiples Filas (Multi-Row Subqueries):

• 📌 Definición: Retornan múltiples filas (típicamente 1 columna)
• 🔧 Uso: Operadores IN, NOT IN, ANY, ALL, EXISTS
• ✅ Ejemplo: (SELECT department_id FROM departments WHERE location = 'NYC')

En Codigo Fuente Pro cubrimos SQL avanzado y optimización de queries.

🔍 Subqueries en WHERE: Filtrado Dinámico

La ubicación más común de SQL subqueries ejemplos es la cláusula WHERE para filtrado basado en resultados de otra query.

💰 Ejemplo 1: Empleados con Salario Mayor al Promedio

-- Encontrar empleados que ganan más que el salario promedio
SELECT 
    employee_id,
    first_name,
    last_name,
    salary
FROM employees
WHERE salary > (
    SELECT AVG(salary) 
    FROM employees
);

-- Resultado: empleados con salary > 75000 (si promedio es 75000)

Explicación paso a paso:

1. Subquery ejecuta primero: (SELECT AVG(salary) FROM employees) calcula promedio (ej: 75000)
2. Valor retornado sustituye subquery: Query se convierte en WHERE salary > 75000
3. Query externa filtra: Retorna solo empleados cumpliendo condición

📋 Ejemplo 2: Operador IN con Múltiples Valores

-- Encontrar empleados que trabajan en departamentos ubicados en 'New York'
SELECT 
    employee_id,
    first_name,
    last_name,
    department_id
FROM employees
WHERE department_id IN (
    SELECT department_id 
    FROM departments 
    WHERE location = 'New York'
);

-- IN acepta múltiples valores retornados por subquery
-- Si subquery retorna (10, 20, 30), equivale a:
-- WHERE department_id IN (10, 20, 30)

🚫 Ejemplo 3: NOT IN para Exclusión

-- Encontrar empleados SIN órdenes asignadas
SELECT 
    employee_id,
    first_name,
    last_name
FROM employees
WHERE employee_id NOT IN (
    SELECT DISTINCT employee_id 
    FROM orders
);

-- IMPORTANTE: DISTINCT elimina duplicados para eficiencia
-- NOT IN excluye empleados que aparecen en orders

⚖️ Operadores ANY y ALL

-- ANY: cumple condición con AL MENOS UN valor de subquery
SELECT product_name, price
FROM products
WHERE price > ANY (
    SELECT price 
    FROM products 
    WHERE category = 'Electronics'
);
-- Retorna productos con precio mayor que CUALQUIER producto Electronics

-- ALL: cumple condición con TODOS los valores de subquery
SELECT product_name, price
FROM products
WHERE price > ALL (
    SELECT price 
    FROM products 
    WHERE category = 'Electronics'
);
-- Retorna productos con precio mayor que EL MÁS CARO producto Electronics

📊 Subqueries en SELECT: Columnas Calculadas

Las subqueries en SELECT de SQL subqueries ejemplos permiten añadir columnas calculadas sin modificar FROM clause.

📈 Ejemplo 4: Comparación Individual vs Promedio

-- Listar empleados con su salario y el salario promedio para comparación
SELECT 
    employee_id,
    first_name,
    last_name,
    salary,
    (SELECT AVG(salary) FROM employees) AS avg_salary,
    salary - (SELECT AVG(salary) FROM employees) AS salary_difference
FROM employees
ORDER BY salary DESC;

-- Resultado:
-- employee_id | first_name | salary | avg_salary | salary_difference
-- 101         | John       | 120000 | 75000      | +45000
-- 102         | Jane       | 95000  | 75000      | +20000
-- 103         | Bob        | 65000  | 75000      | -10000

📦 Ejemplo 5: Conteo Relacionado por Fila

-- Listar departamentos con total de empleados en cada uno
SELECT 
    department_id,
    department_name,
    (SELECT COUNT(*) 
     FROM employees e 
     WHERE e.department_id = d.department_id) AS employee_count
FROM departments d;

-- Esta es SUBQUERY CORRELACIONADA (referencia tabla outer query 'd')

🗂️ Subqueries en FROM: Derived Tables

Subqueries en FROM crean tablas temporales virtuales (derived tables o inline views) en SQL subqueries ejemplos avanzados.

💼 Ejemplo 6: Tabla Derivada con Agregaciones

-- Calcular estadísticas de ventas por categoría
SELECT 
    c.category_name,
    sales_stats.total_sales,
    sales_stats.avg_price,
    sales_stats.product_count
FROM categories c
JOIN (
    SELECT 
        category_id,
        SUM(quantity * price) AS total_sales,
        AVG(price) AS avg_price,
        COUNT(DISTINCT product_id) AS product_count
    FROM sales
    GROUP BY category_id
) AS sales_stats ON c.category_id = sales_stats.category_id
ORDER BY total_sales DESC;

-- Subquery en FROM crea tabla temporal 'sales_stats'
-- Alias 'sales_stats' es OBLIGATORIO para referenciar columnas

🏆 Ejemplo 7: Top N por Grupo

-- Top 3 productos más vendidos por categoría
SELECT 
    category_name,
    product_name,
    total_sold,
    rank_in_category
FROM (
    SELECT 
        c.category_name,
        p.product_name,
        SUM(s.quantity) AS total_sold,
        ROW_NUMBER() OVER (PARTITION BY c.category_id ORDER BY SUM(s.quantity) DESC) AS rank_in_category
    FROM products p
    JOIN categories c ON p.category_id = c.category_id
    JOIN sales s ON p.product_id = s.product_id
    GROUP BY c.category_id, c.category_name, p.product_id, p.product_name
) AS ranked_products
WHERE rank_in_category <= 3
ORDER BY category_name, rank_in_category;

🎬 Video: SQL Subqueries Tutorial Completo con Ejemplos

🔗 Subqueries Correlacionadas vs No-Correlacionadas

Diferencia crítica en SQL subqueries ejemplos que impacta dramáticamente performance.

⚡ No-Correlacionadas (Independientes)

Subquery NO referencia columnas de outer query. Se ejecuta UNA SOLA VEZ y resultado es reutilizado.

-- NO-CORRELACIONADA: Subquery se ejecuta 1 vez
SELECT employee_id, first_name, salary
FROM employees
WHERE salary > (
    SELECT AVG(salary) FROM employees
);

-- Ejecución:
-- 1. Subquery calcula AVG(salary) = 75000 (ejecuta 1 vez)
-- 2. Query externa usa resultado: WHERE salary > 75000
-- Complejidad: O(N) - lineal

🔄 Correlacionadas (Dependientes)

Subquery REFERENCIA columnas de outer query. Se ejecuta MÚLTIPLES VECES (una por cada fila evaluada).

-- CORRELACIONADA: Subquery se ejecuta N veces
SELECT 
    e1.employee_id,
    e1.first_name,
    e1.salary,
    e1.department_id
FROM employees e1
WHERE e1.salary > (
    SELECT AVG(e2.salary) 
    FROM employees e2 
    WHERE e2.department_id = e1.department_id  -- ← CORRELACIÓN
);

-- Ejecución:
-- Para cada fila e1:
--   1. Subquery calcula AVG(salary) para department_id específico de e1
--   2. Compara e1.salary con ese promedio
-- Si tabla tiene 10,000 filas → subquery ejecuta 10,000 veces!
-- Complejidad: O(N×M) - cuadrática en peor caso

⚠️ Impacto Performance

• ❌ Correlacionadas lentas: N filas outer query × M filas subquery = N×M operaciones
• ✅ No-correlacionadas rápidas: 1 ejecución subquery + N filas outer = 1+N operaciones
• 🎯 Solución: Convertir correlacionadas a JOIN cuando posible

🔄 Conversión Correlacionada → JOIN

-- ANTES: Correlacionada (lenta)
SELECT e1.employee_id, e1.first_name, e1.salary
FROM employees e1
WHERE e1.salary > (
    SELECT AVG(e2.salary) 
    FROM employees e2 
    WHERE e2.department_id = e1.department_id
);

-- DESPUÉS: JOIN (rápida)
SELECT e.employee_id, e.first_name, e.salary
FROM employees e
JOIN (
    SELECT department_id, AVG(salary) AS avg_dept_salary
    FROM employees
    GROUP BY department_id
) AS dept_avg ON e.department_id = dept_avg.department_id
WHERE e.salary > dept_avg.avg_dept_salary;

-- Performance: O(N×M) → O(N+M) con índices apropiados

 

✅ EXISTS y NOT EXISTS: Checks de Existencia

EXISTS es operador especializado en SQL subqueries ejemplos optimizado para verificar existencia sin retornar datos.

🎯 EXISTS – Verificar Existencia

-- Encontrar clientes que han realizado AL MENOS UNA orden
SELECT customer_id, customer_name
FROM customers c
WHERE EXISTS (
    SELECT 1 
    FROM orders o 
    WHERE o.customer_id = c.customer_id
);

-- EXISTS retorna TRUE si subquery devuelve ≥1 fila, FALSE si 0 filas
-- SELECT 1 es convención (puede ser SELECT *, SELECT NULL, etc)
-- Optimizer cortocircuita en primera coincidencia (no procesa todas filas)

🚫 NOT EXISTS – Verificar NO Existencia

-- Encontrar clientes SIN órdenes (nunca han comprado)
SELECT customer_id, customer_name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1 
    FROM orders o 
    WHERE o.customer_id = c.customer_id
);

-- Equivalente a LEFT JOIN + IS NULL pero frecuentemente más rápido

⚡ EXISTS vs IN Performance

-- EXISTS (recomendado - más rápido)
SELECT customer_id, customer_name
FROM customers c
WHERE EXISTS (
    SELECT 1 
    FROM orders o 
    WHERE o.customer_id = c.customer_id
);

-- IN (puede ser más lento en datasets grandes)
SELECT customer_id, customer_name
FROM customers
WHERE customer_id IN (
    SELECT DISTINCT customer_id FROM orders
);

-- Diferencias:
-- EXISTS: Para al encontrar primera coincidencia (cortocircuito)
-- IN: Debe construir lista completa de valores primero
-- EXISTS generalmente 2-5x más rápido en tablas >10k filas

🛠️ Casos de Uso Avanzados SQL Subqueries

Aplicaciones prácticas complejas de SQL subqueries ejemplos en escenarios reales business.

📊 Ejemplo 8: Percentiles y Rankings

-- Encontrar empleados en top 10% de salarios
SELECT 
    employee_id,
    first_name,
    last_name,
    salary,
    (SELECT COUNT(*) FROM employees) AS total_employees,
    (SELECT COUNT(*) FROM employees e2 WHERE e2.salary >= e1.salary) AS rank_position
FROM employees e1
WHERE salary >= (
    SELECT PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY salary)
    FROM employees
);

🔍 Ejemplo 9: Detectar Duplicados

-- Encontrar emails duplicados en tabla users
SELECT email, COUNT(*) AS duplicate_count
FROM users
WHERE email IN (
    SELECT email 
    FROM users 
    GROUP BY email 
    HAVING COUNT(*) > 1
)
GROUP BY email
ORDER BY duplicate_count DESC;

📅 Ejemplo 10: Análisis Temporal con Subqueries

-- Comparar ventas mes actual vs mes anterior
SELECT 
    DATE_TRUNC('month', sale_date) AS month,
    SUM(amount) AS current_month_sales,
    (SELECT SUM(amount) 
     FROM sales s2 
     WHERE DATE_TRUNC('month', s2.sale_date) = DATE_TRUNC('month', s1.sale_date) - INTERVAL '1 month'
    ) AS previous_month_sales,
    SUM(amount) - (SELECT SUM(amount) 
                   FROM sales s2 
                   WHERE DATE_TRUNC('month', s2.sale_date) = DATE_TRUNC('month', s1.sale_date) - INTERVAL '1 month'
    ) AS month_over_month_change
FROM sales s1
GROUP BY DATE_TRUNC('month', sale_date)
ORDER BY month DESC;

⚙️ Optimización y Mejores Prácticas

Cómo escribir SQL subqueries ejemplos performantes y mantenibles en 2026.

✅ Mejores Prácticas Subqueries

• 🎯 Preferir EXISTS sobre IN: Mejor performance para checks existencia en tablas grandes
• 🚀 Evitar correlacionadas cuando posible: Convertir a JOIN o CTE si impacta performance
• 📊 Usar EXPLAIN ANALYZE: Analizar plan ejecución identificar bottlenecks
• 🔢 DISTINCT en subqueries IN: Eliminar duplicados reduce comparaciones
• 📏 Limitar profundidad anidamiento: Max 2-3 niveles para readability
• 💾 Índices apropiados: Columnas en WHERE subquery deben tener índices
• 🔄 Considerar CTEs: WITH clauses más legibles para queries complejas

🔄 Alternativas a Subqueries

1. Common Table Expressions (CTEs):

-- Subquery anidada (menos legible)
SELECT * 
FROM (
    SELECT * 
    FROM (
        SELECT employee_id, salary 
        FROM employees 
        WHERE salary > 50000
    ) AS high_earners
    WHERE salary < 100000 ) AS mid_range; -- CTE (más legible) WITH high_earners AS ( SELECT employee_id, salary FROM employees WHERE salary > 50000
),
mid_range AS (
    SELECT * 
    FROM high_earners 
    WHERE salary < 100000
)
SELECT * FROM mid_range;

2. JOINs en lugar de subqueries:

-- Subquery
SELECT e.employee_id, e.first_name
FROM employees e
WHERE e.department_id IN (
    SELECT department_id 
    FROM departments 
    WHERE location = 'NYC'
);

-- JOIN (frecuentemente más rápido)
SELECT e.employee_id, e.first_name
FROM employees e
INNER JOIN departments d ON e.department_id = d.department_id
WHERE d.location = 'NYC';

⚠️ Cuándo Evitar Subqueries

• ❌ Correlacionadas en tablas >100k filas: Performance terrible, usar JOIN
• ❌ Múltiples subqueries idénticas: Calcular una vez, guardar en CTE/variable
• ❌ Subqueries sin índices: Full table scan cada ejecución = desastre
• ❌ Anidamiento >3 niveles: «Callback hell SQL», refactorizar con CTEs

📊 EXPLAIN ANALYZE – Análisis Performance

-- Analizar plan ejecución
EXPLAIN ANALYZE
SELECT employee_id, first_name, salary
FROM employees
WHERE salary > (SELECT AVG(salary) FROM employees);

-- Resultado muestra:
-- - Seq Scan vs Index Scan (índices usados?)
-- - Execution time (ms)
-- - Rows processed
-- - Subquery execution cost

🏁 Conclusión

Dominar SQL subqueries ejemplos es habilidad avanzada indispensable para cualquier profesional trabajando con bases de datos en 2026, permitiendo resolver problemas analíticos complejos, filtrados dinámicos multi-tabla, agregaciones anidadas y comparaciones contextuales que serían imposibles con queries simples SELECT-FROM-WHERE. A lo largo de esta guía exhaustiva hemos explorado definiciones técnicas (subquery = consulta SELECT anidada entre paréntesis dentro otra query), tipos fundamentales (scalar retorna 1 valor, single-row retorna 1 fila, multi-row retorna múltiples filas usadas con IN/ANY/ALL/EXISTS), posicionamiento estratégico (WHERE para filtrado dinámico, SELECT para columnas calculadas, FROM para derived tables, HAVING para filtros agregados), diferencia CRÍTICA correlacionadas vs no-correlacionadas (correlacionadas ejecutan N veces referenciando outer query = O(N×M) complejidad potencialmente lenta, no-correlacionadas ejecutan 1 vez = O(N) rápido), operadores especializados (EXISTS más performante que IN para checks existencia con cortocircuito primera coincidencia, NOT EXISTS para anti-joins), y casos uso avanzados (percentiles top 10%, detección duplicados, análisis temporal month-over-month, rankings por grupo con window functions).

Las mejores prácticas 2026 incluyen preferir EXISTS sobre IN (2-5x más rápido tablas >10k filas), evitar subqueries correlacionadas cuando posible convirtiendo a JOIN (O(N×M) → O(N+M) con índices), usar DISTINCT en subqueries IN eliminar duplicados, limitar anidamiento 2-3 niveles máximo (readability crítica mantenimiento), índices apropiados columnas WHERE subquery (sin índices = full table scan desastroso), considerar CTEs (WITH clauses) para queries complejas multi-paso (modularidad legibilidad), analizar planes ejecución EXPLAIN ANALYZE identificar bottlenecks (seq scan vs index scan, execution time, rows processed). Alternativas modernas: CTEs ofrecen misma funcionalidad sintaxis limpia modular especialmente queries >100 líneas, JOINs frecuentemente más performantes que subqueries IN cuando necesitas columnas ambas tablas output, window functions (ROW_NUMBER, RANK, LEAD/LAG) reemplazan muchos casos uso subqueries correlacionadas rankings/comparaciones.

El momento de dominar SQL subqueries ejemplos es AHORA en tus proyectos analytics/backend. Comienza simple: reescribe filtros estáticos con subqueries escalares (WHERE salary > (SELECT AVG(salary) FROM employees)), practica IN subqueries para filtros multi-valor (WHERE department_id IN (SELECT…)), experimenta EXISTS para checks existencia (clientes con/sin órdenes), construye derived tables FROM subqueries (estadísticas agregadas como tablas temporales). Progresa avanzado: implementa subqueries correlacionadas calculando métricas por-fila contextuales (salario empleado vs promedio su departamento), usa window functions combinadas subqueries (rankings percentiles top N por categoría), optimiza performance convirtiendo correlacionadas lentas a JOINs (EXPLAIN ANALYZE antes/después comparar improvement), refactoriza queries complejas multi-paso con CTEs modularidad. Mide siempre: EXPLAIN ANALYZE es tu mejor amigo – 1000ms query puede optimizarse a 50ms con índice apropiado o restructuración JOIN vs subquery. ¡Subqueries bien aplicadas transforman queries imposibles en soluciones elegantes 10 líneas!

❓ Preguntas Frecuentes sobre SQL Subqueries

🔹 ¿Cuándo debo usar subquery vs JOIN?

Elegir entre subquery y JOIN en SQL subqueries ejemplos depende de múltiples factores técnicos y contextuales. USA SUBQUERY cuando: (1) Solo necesitas filtrar, no datos relacionados: Si solo quieres empleados del departamento ‘Engineering’ pero no necesitas columnas de tabla departments en output, subquery WHERE es más limpio: WHERE department_id IN (SELECT id FROM departments WHERE name = 'Engineering') vs JOIN contamina SELECT clause, (2) Checks existencia: EXISTS subquery es MÁS RÁPIDO que LEFT JOIN + IS NULL: WHERE EXISTS (SELECT 1 FROM orders WHERE customer_id = c.id) cortocircuita en primera coincidencia vs JOIN procesa todas filas, (3) Agregaciones contextuales: «Empleados con salario > promedio su departamento» natural con correlacionada: WHERE salary > (SELECT AVG(salary) FROM employees e2 WHERE e2.dept = e1.dept), (4) Columnas calculadas SELECT: Añadir columna derivada sin modificar FROM: SELECT name, (SELECT COUNT(*) FROM orders WHERE...) AS order_count. USA JOIN cuando: (1) Necesitas columnas ambas tablas:

Si output requiere employee.name + department.location, JOIN obligatorio, (2) Performance crítica tablas grandes: JOIN con índices apropiados O(N+M) vs subquery correlacionada O(N×M) puede ser 10-100x más rápido, (3) Queries complejas multi-tabla: 5+ tablas relacionadas más legibles con JOINs explícitos que subqueries anidadas, (4) Actualizaciones/deletes basados en otra tabla: UPDATE…FROM JOIN más eficiente que UPDATE WHERE id IN (subquery). REGLA GENERAL: Si subquery correlacionada ejecuta >1000 veces (tabla outer >1000 filas), considera JOIN. Si solo filtras y no necesitas datos relacionados, subquery más limpio. Siempre EXPLAIN ANALYZE ambas versiones comparar performance real.

🔹 ¿Por qué mi subquery correlacionada es tan lenta?

Subqueries correlacionadas en SQL subqueries ejemplos pueden ser exponencialmente lentas por diseño arquitectónico de ejecución. CAUSA RAÍZ PERFORMANCE: Subquery correlacionada referencia columnas outer query, forzando re-ejecución para CADA fila evaluada. Ejemplo: SELECT e1.name, e1.salary FROM employees e1 WHERE e1.salary > (SELECT AVG(e2.salary) FROM employees e2 WHERE e2.department_id = e1.department_id). Si tabla employees tiene 10,000 filas: (1) Query externa procesa fila 1 (employee_id=1, department_id=5), (2) Subquery ejecuta calculando AVG(salary) WHERE department_id=5, (3) Compara e1.salary con resultado, (4) Repite pasos 1-3 para 9,999 filas restantes. Total: 10,000 ejecuciones subquery. Si cada departamento tiene 200 empleados promedio: 10,000 × 200 = 2,000,000 filas procesadas vs 10,000 + operación GROUP BY única con JOIN. SOLUCIONES OPTIMIZACIÓN: (1) Convertir a JOIN: SELECT e.name, e.salary FROM employees e JOIN (SELECT department_id, AVG(salary) AS avg_sal FROM employees GROUP BY department_id) dept ON e.department_id = dept.department_id WHERE e.salary > dept.avg_sal –

ejecuta GROUP BY UNA VEZ, luego JOIN O(N+M) con índices, (2) Índices apropiados: CREATE INDEX idx_dept ON employees(department_id) – si correlacionada inevitable, índice permite lookup rápido, (3) Materializar subquery con CTE: WITH dept_avg AS (SELECT department_id, AVG(salary) AS avg_sal FROM employees GROUP BY department_id) SELECT... – calcula una vez, reutiliza, (4) LATERAL JOIN (PostgreSQL): SELECT e.*, dept.avg_sal FROM employees e JOIN LATERAL (SELECT AVG(salary) AS avg_sal FROM employees WHERE department_id = e.department_id) dept ON true – sintaxis correlacionada pero optimizada. MEDICIÓN: EXPLAIN ANALYZE muestra «loops=N» indicando cuántas veces ejecutó subquery – si N > 100, optimizar urgentemente.

🔹 ¿Puedo usar múltiples subqueries anidadas y hasta qué profundidad?

SQL soporta múltiples niveles anidamiento subqueries en SQL subqueries ejemplos pero existen límites técnicos y prácticos críticos. LÍMITES TÉCNICOS: Mayoría databases SQL permiten hasta 32 niveles anidamiento teóricamente (SQL Server documentación oficial, PostgreSQL similar, MySQL 255 niveles). Ejemplo válido 3 niveles: SELECT * FROM t1 WHERE col1 IN (SELECT col2 FROM t2 WHERE col3 IN (SELECT col4 FROM t3 WHERE col5 IN (SELECT col6 FROM t4))). Pero limits varían: Oracle 255 niveles, SQL Server 32, depende memoria disponible y complejidad expresiones. LÍMITES PRÁCTICOS (Recomendaciones): (1) Máximo 2-3 niveles readability: Código mantenible requiere comprensión rápida – 4+ niveles anidados son «callback hell SQL» donde developers pierden contexto qué hace cada nivel, (2) Performance degradation: Cada nivel añade overhead parsing/execution – 5 niveles anidados pueden convertir query 100ms en 5000ms, especialmente con correlacionadas, (3) Debugging nightmare: Error sintaxis o lógica en subquery nivel 4 extremadamente difícil identificar/corregir vs query plana o CTEs modularizadas.

ALTERNATIVAS SUPERIORES: (1) CTEs (WITH clauses): Modularizar queries complejas: WITH level1 AS (...), level2 AS (...), level3 AS (...) SELECT * FROM level3 – cada paso nombrado explícitamente, debuggeable independientemente, (2) Temporary tables: Materializar resultados intermedios: CREATE TEMP TABLE step1 AS SELECT...; CREATE TEMP TABLE step2 AS SELECT... FROM step1 – performance predecible, fácil inspeccionar datos cada paso, (3) Refactorizar lógica: Queries requiriendo 5+ niveles anidamiento típicamente señal diseño database pobre o lógica business incorrectamente modelada en SQL – considerar normalización schema, stored procedures, o procesamiento aplicación. BEST PRACTICE 2026: Si necesitas >2 niveles anidamiento, refactoriza con CTEs primero. Si CTEs >150 líneas, considera temporary tables o múltiples queries separadas con lógica aplicación intermedia.