¿Cómo obtener (SELECT) o actualizar (UPDATE) las filas de una tabla que no existen en otra tabla relaciona en SQL Server? NOT IN, NOT EXISTS y LEFT JOIN (o LEFT OUTER JOIN) ¿Qué opción ofrece un mejor Rendimiento en SQL Server?
|
|
Este Artículo presenta una práctica habitual en el desarrollo de base de datos SQL Server con Transact-SQL (T-SQL): obtener las filas de una tabla que no existen en otra tabla relaciona. Algo habitual cuando no existe Integridad Referencial y en proyectos de Data Warehouse (Business Intelligence). ¿Cómo podemos realizar este tipo de consultas SQL? ¿Qué opción ofrece un mejor Rendimiento en SQL Server? Las alternativas son claras: Utilizar NOT IN junto a una SubConsulta, en la cláusula WHERE; Utilizar LEFT JOIN o LEFT OUTER JOIN en la cláusula FROM, y comprobar nulidad (IS NULL) en la tabla externa; Utilizar NOT EXISTS junto a una SubConsulta, en la cláusula WHERE; Resumiendo, ¿qué alternativa nos da mejor rendimiento? ¿NOT IN, NOT EXISTS, o LEFT JOIN / LEFT OUTER JOIN)? |
Una práctica habitual en el desarrollo de base de datos SQL Server con Transact-SQL (T-SQL), es obtener las filas de una tabla que no existen en otra tabla relaciona en SQL Server. Es decir, si tenemos una tabla Facturas y una tabla Clientes que se relacionan por un campo CodCliente, el caso de este artículo es obtener las Facturas con CodCliente no existente en la tabla Clientes. Un caso real, en entornos de Data Warehouse (Business Intelligence) sin Integridad Referencial, es al intentar identificar en una Tabla de Hechos, aquellas filas que almacenan la clave de una Dimención con valores que no existen en la Tabla de Dimensión (habitualmente, para actualizar dichas filas de la Tabla de Hechos, con los valores clave de la Dimensión asociados a No Aplica o a No Informado, en función de cada caso).
Evidentemente, esta situación ocurre si no se utiliza Integridad Referencial. En cualquier caso, si no utilizamos Integridad Referencial ¿Cómo podemos realizar este tipo de consultas SQL?
- Utilizar NOT IN junto a una SubConsulta, en la cláusula WHERE. Suele ofrecer el peor rendimiento en la mayoría de los casos, pero NO siempre, por lo tanto aunque es recomendable no tomar como costumbre la utilización de NOT IN, tampoco debemos perderlo de vista, ya que en alguna ocasión nos puede sacar de algún apuro (rara vez puede mejorar el rendimiento de consultas, pero puede ocurrir). Suele generar un código Transact-SQL (T-SQL) bastante claro (no olvidemos, que después del desarrollo, está el mantenimiento ;-)
SELECT *
FROM dbo.Facturas
WHERE CodCliente
NOT IN (SELECT CodCliente
FROM dbo.Clientes)
|
Una desventaja de utilizar NOT IN, es que sólo permite unir por un campo, salvo que recurramos a la utilización de concatenaciones o trucos similares... asumiendo su coste en el rendimiento de SQL Server, impacto en el Plan de Ejecución, etc.
SELECT *
FROM dbo.Facturas
WHERE CodCliente1 + '-' + CodCliente2
NOT IN (SELECT CodCliente1 + '-' + CodCliente2
FROM dbo.Clientes)
|
- Utilizar LEFT JOIN o LEFT OUTER JOIN en la cláusula FROM, y comprobar nulidad (IS NULL) en la tabla externa. Suele ofrecer el mejor rendimiento en la mayoría de los casos, por lo que es recomendable tomar como costumbre la utilización de LEFT JOIN (o LEFT OUTER JOIN), aunque podríamos encontrarnos con alguna excepción. Suele generar un código Transact-SQL (T-SQL) bastante claro (no olvidemos, que después del desarrollo, está el mantenimiento ;-)
SELECT *
FROM dbo.Facturas F
LEFT OUTER JOIN dbo.Clientes C
ON F.CodCliente = C.CodCliente
WHERE C.CodCliente IS NULL
|
Además, permite unir por uno o por varios campos, de forma fácil y sencilla (modificando la cláusula ON del FROM). Otro motivo, para tomar como costumbre la utilización de LEFT JOIN o LEFT OUTER JOIN.
SELECT *
FROM dbo.Facturas F
LEFT OUTER JOIN dbo.Clientes C
ON F.CodCliente1 = C.CodCliente1
AND F.CodCliente2 = C.CodCliente2
WHERE C.CodCliente IS NULL
|
- Utilizar NOT EXISTS junto a una SubConsulta, en la cláusula WHERE. Se supone que genera el mismo Plan de Ejecución que LEFT JOIN o LEFT OUTER JOIN, y en consecuencia, que se obtiene el mismo rendimiento (mismas operaciones de entrada/salida - I/O -, mismos resultados temporales en TEMPDB - WorkTables -, etc.). Bajo mi punto de vista (y esta es una valoración personal), me parece más claro el código Transact-SQL (T-SQL) con LEFT JOIN ó LEFT OUTER JOIN, pero también muchos otros no ven dicha diferencia de claridad en el código.
SELECT *
FROM dbo.Facturas F
WHERE NOT EXISTS (
SELECT
FROM dbo.Clientes C
WHERE F.CodCliente = C.CodCliente)
|
También permite unir por uno o por varios campos, de forma fácil y sencilla (modificando la cláusula WHERE de la SubConsulta).
SELECT *
FROM dbo.Facturas F
WHERE NOT EXISTS (
SELECT
FROM dbo.Clientes C
WHERE F.CodCliente1 = C.CodCliente1
AND F.CodCliente2 = C.CodCliente2)
|
En las consultas mostradas como ejemplo, la utilización de LEFT JOIN (o LEFT OUTER JOIN) y de NOT EXISTS generaba una tabla con resultados intermedios (WorkTable) en TEMPDB, como se puede comprobar con la utilización de SET STATISTICS IO ON. Por el contrario, la utilización de NOT IN emplea dos tablas con resultados intermedios (WorkTable) en TEMPDB, también comprobado con SET STATISTICS IO ON.
También quiero comentar una anécdota que me ocurrió en un cliente. Existía un proceso que ejecutaba múltiples consultas con la sintaxis de NOT IN. Dicho proceso ofrecía un tiempo de ejecución de 6 minutos (o mayor, cuando la máquina estaba más cargada). En una ocasión, dicho proceso empezó a tomar una hora de tiempo de ejecución. Al depurar dicho proceso, la utilización de la sintaxis LEFT JOIN (o LEFT OUTER JOIN) implicaba un tiempo de ejecución de 1 minuto en igualdad de condiciones. Tras un reinicio de la instancia de SQL Server, al volver a ejecutar el mismo proceso, se volvió a los 6 minutos, mientras que con LEFT JOIN (o LEFT OUTER JOIN) se mantenía 1 minuto de tiempo de ejecución. A mí, si me lo cuentan no me lo creo… pero claro, como al que le tocó depurar ese código fue a mí, claro que me creo.. claro que sí ;-)
Poco más, salvo como moraleja recordar que en la mayoría de los caso (que no todos) es mejor LEFT JOIN (o LEFT OUTER JOIN) que NOT IN, en función de la definición de las tablas, la definición de sus índices, el volumen de datos, las estadísticas, etc. Dejo un par de enlaces de interés:
SQL SERVER - Better Performance - LEFT JOIN or NOT IN?SQL SERVER - Better Performance - LEFT JOIN or NOT IN?
http://blog.sqlauthority.com/2008/04/22/sql-server-better-performance-left-join-or-not-in/
Frequently Asked Questions - SELECT Statement (mirar la pregunta número 3)
http://www.sql-server-helper.com/faq/select-p01.html/ |
|
|
|
