Joins en SQL

Visión General

Los JOINs en SQL combinan filas de dos o más tablas basándose en una columna relacionada. Son una de las capacidades más poderosas y frecuentemente mal entendidas de las bases de datos relacionales. Los cuatro tipos comunes de JOIN con un esquema realista de users y orders.

Cuándo Usar

Usa JOINs cuando:

• Necesites datos de múltiples tablas en un solo resultado. Consulta Database Views para consultas reutilizables.
• Esquemas normalizados dividan datos relacionados entre tablas (ej. users, orders, products)
• Reportes o análisis requieran datos agregados de varias fuentes. Consulta Query Optimization para rendimiento.
• Quieras encontrar registros huérfanos o no coincidentes (ej. usuarios sin órdenes). Consulta Soft Deletes para manejo de datos faltantes.

Solución

Schema

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    user_id INT,
    amount DECIMAL(10,2)
);

INSERT INTO users VALUES (1, 'Ada'), (2, 'Bob'), (3, 'Chen');
INSERT INTO orders VALUES (101, 1, 250.00), (102, 1, 75.50), (103, 2, 120.00);

INNER JOIN (solo filas coincidentes)

SELECT u.name, o.order_id, o.amount
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;

name	order_id	amount
Ada	101	250.00
Ada	102	75.50
Bob	103	120.00

Chen no tiene órdenes, así que Chen no aparece.

LEFT JOIN (todas de la izquierda, coincidentes de la derecha)

SELECT u.name, o.order_id, o.amount
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;

name	order_id	amount
Ada	101	250.00
Ada	102	75.50
Bob	103	120.00
Chen	NULL	NULL

Chen aparece con NULLs para órdenes faltantes.

RIGHT JOIN (todas de la derecha, coincidentes de la izquierda)

SELECT u.name, o.order_id, o.amount
FROM users u
RIGHT JOIN orders o ON u.user_id = o.user_id;

Mismo resultado que INNER JOIN aquí porque cada orden tiene un usuario. En la práctica, RIGHT JOIN es raro; intercambia el orden de las tablas y usa LEFT JOIN.

FULL OUTER JOIN (todas las filas de ambas)

SELECT u.name, o.order_id, o.amount
FROM users u
FULL OUTER JOIN orders o ON u.user_id = o.user_id;

Devuelve todos los usuarios y todas las órdenes, con NULLs donde no hay coincidencia en algún lado. No soportado en MySQL; usa UNION de LEFT y RIGHT joins como workaround.

Explicación

• INNER JOIN: devuelve solo filas donde la condición de join coincide en ambas tablas. Úsalo cuando solo te importen pares completos y válidos.
• LEFT JOIN: devuelve cada fila de la tabla izquierda, más filas coincidentes de la derecha. Úsalo cuando quieras todos los registros primarios aunque algunos carezcan de datos relacionados.
• RIGHT JOIN: el espejo de LEFT JOIN. Raramente usado porque invertir el orden de las tablas y usar LEFT JOIN es más intuitivo.
• FULL OUTER JOIN: devuelve todas las filas de ambas tablas. Útil para encontrar registros completamente no coincidentes en cualquier lado.

Variantes

Objetivo	Tipo de Join
Solo pares coincidentes	INNER JOIN
Todos los usuarios, con totales de órdenes	LEFT JOIN + GROUP BY
Usuarios sin órdenes	LEFT JOIN + WHERE o.user_id IS NULL
Órdenes sin usuarios (datos corruptos)	RIGHT JOIN o LEFT JOIN con tablas intercambiadas
Todos los registros de ambas	FULL OUTER JOIN (o UNION en MySQL)

Lo que funciona

• Indexa claves foráneas: la columna de join (orders. user_id) debería tener un índice o constraint de foreign key. Consulta Query Optimization para indexación. Sin él, tablas grandes hacen full scans.
• Usa aliases de tabla: users u hace las consultas legibles y más cortas.
• Sé explícito: escribe INNER JOIN en lugar de solo JOIN — comunica la intención claramente.
• Filtra en la cláusula ON para lógica de join, WHERE para filtrado de resultados: ON u. id = o. user_id AND o. amount > 100 se comporta diferente que WHERE o. amount > 100 con LEFT JOINs.
• Cuidado con productos cartesianos: olvidar la cláusula ON multiplica cada fila de la tabla A por cada fila de la tabla B.

Errores Comunes

• Usar LEFT JOIN cuando se necesita INNER JOIN: esto produce filas NULL que el código downstream puede no esperar.
• Join en la columna equivocada: ON u. name = o. user_id compila pero da resultados sin sentido.
• Consultas N+1 en código de aplicación: obtener una lista de usuarios y luego consultar órdenes para cada uno individualmente es más lento que un solo JOIN. Consulta Caching para reducción de queries.
• Índices faltantes: JOINs en columnas sin indexar son rápidos en desarrollo con 100 filas y catastróficos en producción con millones.
• Joins implícitos: tablas separadas por coma en la cláusula FROM (FROM users, orders) son propensos a errores; siempre usa sintaxis de JOIN explícita.

Buenas prácticas adicionales

6. Usa COALESCE para manejo de NULLs. Reemplaza NULLs con valores por defecto en los resultados para evitar errores downstream:

SELECT u.name, COALESCE(SUM(o.amount), 0) AS total
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
GROUP BY u.user_id, u.name;

7. Califica nombres de columna en queries multi-tabla. Evita ambigüedad prefijando con aliases de tabla:

SELECT u.name, o.amount
FROM users u
JOIN orders o ON u.user_id = o.user_id
WHERE u.active = true;

8. Usa EXISTS en lugar de INNER JOIN para verificaciones de existencia. EXISTS deja de escanear al encontrar la primera coincidencia:

-- Más rápido que INNER JOIN cuando solo necesitas saber si existe coincidencia
SELECT name FROM users u
WHERE EXISTS (
    SELECT 1 FROM orders o WHERE o.user_id = u.user_id
);

9. Limita los result sets con paginación. Resultados grandes de JOIN pueden consumir memoria. Usa LIMIT y OFFSET o paginación por keyset:

SELECT u.name, o.order_id, o.amount
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
ORDER BY u.user_id
LIMIT 50 OFFSET 0;

10. Usa EXPLAIN ANALYZE para verificar la estrategia de join. Verifica si el planner usa nested loops, hash joins o merge joins:

EXPLAIN ANALYZE
SELECT u.name, o.amount
FROM users u
JOIN orders o ON u.user_id = o.user_id;

Tips de Rendimiento

1. Indexa todas las columnas de join. La optimización más impactante. Las claves foráneas deberían tener índices en la tabla hija.

2. Usa ANALYZE después de cambios grandes de datos. El query planner necesita estadísticas precisas para elegir estrategias de join óptimas:

ANALYZE users;
ANALYZE orders;

3. Reduce los result sets intermedios. Filtra con WHERE antes de hacer join para reducir el número de filas procesadas:

-- Mejor: filtrar primero
SELECT u.name, o.amount
FROM users u
JOIN orders o ON u.user_id = o.user_id
WHERE u.active = true AND o.amount > 100;

-- Peor: join todo y luego filtrar

4. Usa covering indexes. Si el índice incluye todas las columnas necesarias para la query, la base de datos evita acceder a la tabla:

CREATE INDEX idx_orders_user_amount ON orders(user_id, amount);

5. Evita condiciones OR entre tablas. El optimizador frecuentemente no puede usar índices eficientemente con OR entre tablas joined. Divide en queries UNION:

-- Frecuentemente más rápido que una sola query con OR entre tablas
SELECT u.name FROM users u JOIN orders o ON u.user_id = o.user_id WHERE o.amount > 500
UNION
SELECT u.name FROM users u JOIN returns r ON u.user_id = r.user_id WHERE r.amount > 500;