sentencias sql con igual a vs en


Digamos que alguien se acercó a ti y dijo que vamos a reducir la cantidad de SQL que escribimos reemplazando igual con IN. El uso sería tanto para valores escalares simples como para listas de números.

SELECT * 
  FROM table 
 WHERE id = 1

O

SELECT * 
  FROM table 
 WHERE id IN (1)

¿Son estas declaraciones equivalentes a lo que produce el optimizador?

Esto parece realmente simple en la superficie, pero conduce a la simplificación por dos razones: 1. los bloques grandes de SQL no necesitan ser duplicados, y 2. no abusamos de la dinámica SQL.

Este es un ejemplo artificial, pero considere lo siguiente.

select a.* from tablea a 
join tableb b on a.id = b.id
join tablec c on b.id2 = c.id2
left join tabled d on c.id3 = c.id3
where d.type = 1

... y lo mismo para más de un caso

select a.* from tablea a 
join tableb b on a.id = b.id
join tablec c on b.id2 = c.id2
left join tabled d on c.id3 = c.id3
where d.type in (1,2,3,4)

(esto ni siquiera es una declaración grande)

Posiblemente podría hacer concatenación de cadenas, pero esto no es deseable a la luz del uso de OR, y la concatenación dinámica de cadenas SQL siempre comienza con buenas intenciones (al menos en estas partes).

Author: Jithin Shaji, 2012-02-28

2 answers

Los dos producirán el mismo plan de ejecución - ya sea un table scan, index scan, o index seek, dependiendo de si/cómo tiene su tabla indexada.

Puede ver por sí mismo - Mostrando Planes de Ejecución Gráficos (SQL Server Management Studio) - Consulte la sección llamada "Uso de las opciones del Plan de Ejecución".

 25
Author: Jeremy Wiggins,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-02-28 04:31:37

Esas dos declaraciones específicas son equivalentes al optimizador (¿comparó los planes de ejecución?), pero creo que el beneficio más importante que se obtiene de este último es que

WHERE id = 1 OR id = 2 OR id = 3 OR id = 4 OR id = 5

Se puede expresar como la siguiente versión, mucho más concisa y legible (pero semánticamente equivalente al optimizador):

WHERE id IN (1,2,3,4,5)

El problema es que cuando se expresa como este último, la mayoría de la gente piensa que puede pasar una cadena, como @list = '1,2,3,4,5' y luego decir:

WHERE id IN (@list)

Esto no funciona porque @list es una sola cadena escalar, y no una matriz de enteros.

Para los casos en los que tienes un solo valor, no veo cómo esa "optimización" ayuda en nada. No has escrito menos SQL, en realidad has escrito más. ¿Puede describir con más detalle cómo esto va a conducir a menos SQL?

 17
Author: Aaron Bertrand,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-02-28 04:26:30