GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

¿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/




Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Junio de 2017 (1)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.