Etiqueta: bases-de-datos

JOIN ON vs WHERE: por qué la ubicación de la condición importa

Concepto fundamental

En SQL, una condición puede colocarse en la cláusula ON del JOIN, o en la cláusula WHERE. Aunque en muchos casos parecen producir el mismo resultado, no siempre son equivalentes, especialmente cuando se usan LEFT JOIN, RIGHT JOIN o FULL OUTER JOIN.

Orden lógico de ejecución

De forma simplificada, SQL procesa una consulta en este orden:

FROM
JOIN
ON
WHERE
GROUP BY
HAVING
SELECT
ORDER BY

FROM
JOIN
ON
WHERE
GROUP BY
HAVING
SELECT
ORDER BY

Esto significa que primero se realizan los JOIN, luego se aplican las condiciones del ON, y después se ejecuta el WHERE sobre el resultado ya obtenido.

Diferencia conceptual

Condición en ON

La condición forma parte del criterio de unión entre las tablas:

SELECT *
FROM tablaA a
JOIN tablaB b
    ON a.id = b.id
   AND b.estado = 'ACTIVO';

SELECT *
FROM tablaA a
JOIN tablaB b
    ON a.id = b.id
   AND b.estado = 'ACTIVO';

Interpretación: une ambas tablas solamente cuando el ID coincida y el registro de B esté ACTIVO.

Condición en WHERE

La unión se realiza primero y luego se filtran los resultados:

SELECT *
FROM tablaA a
JOIN tablaB b
    ON a.id = b.id
WHERE b.estado = 'ACTIVO';

SELECT *
FROM tablaA a
JOIN tablaB b
    ON a.id = b.id
WHERE b.estado = 'ACTIVO';

Interpretación: une ambas tablas por ID y después elimina todas las filas cuyo estado no sea ACTIVO.

Caso 1: INNER JOIN

Tablas de ejemplo:

clientes
id	nombre
1	Ana
2	Luis
3	Pedro

pedidos
id	cliente_id	estado
10	1	ACTIVO
11	1	INACTIVO
12	2	INACTIVO

Opción A: condición en ON

SELECT *
FROM clientes c
INNER JOIN pedidos p
    ON c.id = p.cliente_id
   AND p.estado = 'ACTIVO';

SELECT *
FROM clientes c
INNER JOIN pedidos p
    ON c.id = p.cliente_id
   AND p.estado = 'ACTIVO';

cliente	pedido	estado
Ana	10	ACTIVO

Opción B: condición en WHERE

SELECT *
FROM clientes c
INNER JOIN pedidos p
    ON c.id = p.cliente_id
WHERE p.estado = 'ACTIVO';

SELECT *
FROM clientes c
INNER JOIN pedidos p
    ON c.id = p.cliente_id
WHERE p.estado = 'ACTIVO';

cliente	pedido	estado
Ana	10	ACTIVO

Conclusión para INNER JOIN

En la mayoría de los casos, INNER JOIN ... ON condicion y INNER JOIN ... WHERE condicion producen el mismo resultado. Por eso muchas personas creen erróneamente que siempre es indiferente dónde colocar la condición.

Caso 2: LEFT JOIN

Aquí es donde aparecen los problemas.

LEFT JOIN sin filtros

SELECT *
FROM clientes c
LEFT JOIN pedidos p
    ON c.id = p.cliente_id;

SELECT *
FROM clientes c
LEFT JOIN pedidos p
    ON c.id = p.cliente_id;

cliente	pedido	estado
Ana	10	ACTIVO
Ana	11	INACTIVO
Luis	12	INACTIVO
Pedro	NULL	NULL

Pedro aparece aunque no tenga pedidos — ese es justamente el propósito del LEFT JOIN.

Condición en ON (correcto)

Supongamos que queremos mostrar todos los clientes y únicamente sus pedidos activos:

SELECT *
FROM clientes c
LEFT JOIN pedidos p
    ON c.id = p.cliente_id
   AND p.estado = 'ACTIVO';

SELECT *
FROM clientes c
LEFT JOIN pedidos p
    ON c.id = p.cliente_id
   AND p.estado = 'ACTIVO';

Ana tiene un pedido ACTIVO, se muestra. Luis tiene pedidos pero ninguno ACTIVO, se devuelve NULL. Pedro no tiene pedidos, se devuelve NULL. Todos los clientes siguen apareciendo:

cliente	pedido	estado
Ana	10	ACTIVO
Luis	NULL	NULL
Pedro	NULL	NULL

Condición en WHERE (error típico)

SELECT *
FROM clientes c
LEFT JOIN pedidos p
    ON c.id = p.cliente_id
WHERE p.estado = 'ACTIVO';

SELECT *
FROM clientes c
LEFT JOIN pedidos p
    ON c.id = p.cliente_id
WHERE p.estado = 'ACTIVO';

Primero SQL realiza el LEFT JOIN completo (las 4 filas de arriba), y luego el WHERE elimina todo lo que no sea ACTIVO, incluyendo los NULL. Resultado final:

cliente	pedido	estado
Ana	10	ACTIVO

Problema: desaparecieron Luis y Pedro. El LEFT JOIN terminó comportándose como un INNER JOIN.

La regla más importante

Cuando uses LEFT JOIN, pregúntate: ¿quiero conservar los registros que no tengan coincidencia? Si la respuesta es sí, las condiciones sobre la tabla derecha generalmente deben ir en el ON.

Ejemplo típico en seguros

Supongamos estas tablas:

póliza
P001
P002
P003

póliza	estado
P001	PAGADO
P002	PENDIENTE

Objetivo: mostrar todas las pólizas y solamente los pagos pendientes.

Correcto

SELECT *
FROM polizas p
LEFT JOIN pagos pa
    ON p.poliza = pa.poliza
   AND pa.estado = 'PENDIENTE';

SELECT *
FROM polizas p
LEFT JOIN pagos pa
    ON p.poliza = pa.poliza
   AND pa.estado = 'PENDIENTE';

póliza	estado
P001	NULL
P002	PENDIENTE
P003	NULL

Incorrecto

SELECT *
FROM polizas p
LEFT JOIN pagos pa
    ON p.poliza = pa.poliza
WHERE pa.estado = 'PENDIENTE';

SELECT *
FROM polizas p
LEFT JOIN pagos pa
    ON p.poliza = pa.poliza
WHERE pa.estado = 'PENDIENTE';

póliza	estado
P002	PENDIENTE

Se perdieron P001 y P003.

Regla práctica para el trabajo diario

INNER JOIN

Generalmente da igual si la condición va en el ON o en el WHERE.

LEFT JOIN

Si la condición afecta a la tabla de la derecha:

Normalmente correcto: LEFT JOIN tablaB ON ... AND condicion
Sospechoso: LEFT JOIN tablaB ON ... WHERE tablaB.columna = valor — muchas veces esto destruye el LEFT JOIN.

Truco mental rápido

Si ves un LEFT JOIN seguido de un WHERE que filtra sobre la tabla derecha, detente y pregúntate: ¿quiero eliminar los NULL? Si la respuesta es no, la condición probablemente debe estar en el ON. Si es sí, el WHERE está bien.

Resumen final

Ubicación de la condición	Función
ON	Define cómo se unen las tablas
WHERE	Filtra el resultado después del JOIN
INNER JOIN	Generalmente produce el mismo resultado en ambos casos
LEFT JOIN	Puede cambiar completamente el resultado
ON + LEFT JOIN	Conserva registros sin coincidencia
WHERE + LEFT JOIN	Puede convertirlo en un INNER JOIN

Regla de oro: si utilizas LEFT JOIN y quieres conservar los registros de la tabla izquierda aunque no exista coincidencia en la tabla derecha, coloca las condiciones de la tabla derecha dentro del ON y no en el WHERE.

18/08/2022

Diagnóstico de memoria y versión en SQL Server

Contexto

Servidor de ejemplo con las siguientes características: 30GB de disco, 2 vCPU, 4GB de RAM, collation Modern_Spanish_CI_AS. Este tipo de diagnóstico es útil cuando un servidor de SQL Server empieza a mostrar señales de presión de memoria, o simplemente para confirmar exactamente qué versión y edición está corriendo antes de planificar un cambio.

1. Versión y edición del motor

Lo primero es confirmar exactamente qué se está ejecutando — la edición determina límites como cuánta RAM puede usar el buffer pool:

SELECT
    SERVERPROPERTY('Edition')       AS edition,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('EngineEdition') AS engine_edition;

SELECT
    SERVERPROPERTY('Edition')       AS edition,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('EngineEdition') AS engine_edition;

2. Límite de memoria configurado (max server memory)

SQL Server, por defecto, puede intentar usar prácticamente toda la RAM disponible del servidor si no se configura un límite explícito. Esta consulta muestra qué valor está configurado actualmente:

SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'max server memory (MB)';

SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'max server memory (MB)';

3. Uso total de memoria del proceso SQL Server

Para ver cuánta memoria está usando realmente el proceso completo, incluyendo memoria virtual comprometida:

SELECT
    physical_memory_in_use_kb   / 1024 AS memory_in_use_MB,
    large_page_allocations_kb   / 1024 AS large_page_MB,
    locked_page_allocations_kb  / 1024 AS locked_page_MB,
    total_virtual_address_space_kb / 1024 AS total_virtual_MB,
    virtual_address_space_committed_kb / 1024 AS committed_virtual_MB
FROM sys.dm_os_process_memory;

SELECT
    physical_memory_in_use_kb   / 1024 AS memory_in_use_MB,
    large_page_allocations_kb   / 1024 AS large_page_MB,
    locked_page_allocations_kb  / 1024 AS locked_page_MB,
    total_virtual_address_space_kb / 1024 AS total_virtual_MB,
    virtual_address_space_committed_kb / 1024 AS committed_virtual_MB
FROM sys.dm_os_process_memory;

4. Uso de memoria por tipo (memory clerks)

SQL Server organiza internamente su consumo de memoria en «clerks» según el componente que la usa (buffer pool, caché de planes de ejecución, etc.). Esta consulta agrupa el consumo por tipo, de mayor a menor:

SELECT
    type,
    SUM(pages_kb) / 1024 AS memory_MB
FROM sys.dm_os_memory_clerks
GROUP BY type
ORDER BY memory_MB DESC;

SELECT
    type,
    SUM(pages_kb) / 1024 AS memory_MB
FROM sys.dm_os_memory_clerks
GROUP BY type
ORDER BY memory_MB DESC;

5. Buffer pool específico

El buffer pool es el componente que cachea páginas de datos en memoria para evitar lecturas a disco — es justo lo que las ediciones Express y Standard limitan agresivamente. Esta consulta aísla específicamente cuánto está usando:

SELECT
    SUM(pages_kb) / 1024 AS buffer_pool_MB
FROM sys.dm_os_memory_clerks
WHERE type = 'MEMORYCLERK_SQLBUFFERPOOL';

SELECT
    SUM(pages_kb) / 1024 AS buffer_pool_MB
FROM sys.dm_os_memory_clerks
WHERE type = 'MEMORYCLERK_SQLBUFFERPOOL';

Resumen de lo que responde cada consulta

Pregunta	DMV / Vista utilizada
¿Qué edición y versión está corriendo?	`SERVERPROPERTY`
¿Cuánto está configurado como límite de RAM?	`sys.configurations`
¿Cuánta RAM usa el proceso completo de SQL?	`sys.dm_os_process_memory`
¿Qué componentes están consumiendo más memoria?	`sys.dm_os_memory_clerks`
¿Cuánto usa el buffer pool (el que se limita)?	`sys.dm_os_memory_clerks`

22/06/2022