¿Qué es óptimo? UNION vs DONDE EN (str1, str2, str3)

Question

Estoy escribiendo un programa que envía un correo electrónico a la hora local específica del cliente. Tengo un método .NET que toma una zona horaria & amp; hora y destino y devuelve la hora en esa zona horaria. Así que mi método es seleccionar cada zona horaria distinta en la base de datos, verificar si es la hora correcta usando el método, luego seleccionar a cada cliente de la base de datos con esa (s) zona (s).

La consulta se verá como una de estas. Tenga en cuenta que el orden del conjunto de resultados no importa, por lo que una unión estaría bien. ¿Qué es más rápido o realmente hacen lo mismo?

SELECT email FROM tClient WHERE timezoneID in (1, 4, 9)

o

SELECT email FROM tClient WHERE timezoneID = 1
    UNION ALL SELECT email FROM tClient WHERE timezoneID = 4
    UNION ALL SELECT email FROM tCLIENT WHERE timezoneID = 9

Editar: timezoneID es una clave foránea para tTimezone, una tabla con clave principal timezoneID y varchar (20) fieldzoneName. También fui con WHERE IN porque no tenía ganas de abrir el analizador.

Edit 2: Query procesa 200k filas en menos de 100 ms, así que en este momento ya he terminado.

Answer 1

¡Oye! Estas consultas no son equivalentes.

Los resultados serán los mismos solo si se supone que un correo electrónico pertenece solo a una zona horaria. Por supuesto que sí, sin embargo, el motor SQL no lo sabe y trata de eliminar las duplicidades. Así que la primera consulta debería ser más rápida.

Siempre use UNION ALL, a menos que sepa por qué quiere usar UNION.

Si no está seguro de cuál es la diferencia, consulte esta pregunta SO.

Nota: ese yell pertenece a la versión anterior de la pregunta.

Answer 2

Para la mayoría de las preguntas de rendimiento relacionadas con la base de datos, la respuesta real es ejecutarlo y analizar qué hace la base de datos para su conjunto de datos. Ejecute un plan de explicación o seguimiento para ver si su consulta está alcanzando los índices adecuados o cree índices si es necesario.

Probablemente me gustaría utilizar la primera cláusula IN, ya que contiene la mayor parte de la semántica de lo que quieres. El timezoneID parece una clave principal en alguna tabla de zona horaria, por lo que debe ser una clave externa en el correo electrónico e indexada. Dependiendo del optimizador de DB, creo que debería hacer una exploración de índice en el índice de clave externa.

Answer 3

Mi primera suposición sería que

SELECT email FROM tClient WHERE timezoneID in (1, 4, 9)

será más rápido, ya que solo se requiere un escaneo de la tabla para encontrar los resultados, pero sugiero verificar el plan de ejecución para ambas consultas.

Answer 4

No tengo el Analizador de consultas MS SQL para verificar mi hipótesis, pero creo que la variante WHERE IN sería más rápida porque con el servidor UNION tendrá que realizar 3 exploraciones de tabla mientras que con WHERE IN solo necesitará una. Si tiene un Analizador de consultas, verifique los planes de ejecución para ambas consultas.

En Internet, a menudo puede encontrar sugerencias para evitar el uso de WHERE IN, pero eso se refiere a los casos en que se utilizan subconsultas. Por lo tanto, este caso está fuera del alcance de esta recomendación y, además, es más fácil de leer y comprender.

Answer 5

Creo que hay varias informaciones muy importantes que faltan en la pregunta. En primer lugar, es de gran importancia que el clima timezoneID esté indexado o no, es parte de la clave principal, etc. Recomendaría a todos que echen un vistazo al analizador, pero en mi experiencia, la cláusula WHERE debería ser más rápida, especialmente con un índice. La lógica es algo así como, hay una sobrecarga adicional en la consulta de unión, verificación de tipos, números de columna en cada uno, etc.

Answer 6

En el libro "Ajuste de rendimiento de SQL", los autores encontraron que las consultas de UNION fueron más lentas en los 7 DBMS que probaron (SQL Server 2000, Sybase ASE 12.5, Oracle 9i, DB2, etc.): El último DBMS 'puede haber optimizado esa diferencia, pero es dudoso. Además, el método UNION es mucho más largo y más difícil de mantener (¿qué sucede si desea un tercero?) En comparación con el IN.

A menos que tenga una buena razón para usar UNION, siga con el método OR / IN.

Answer 7

Algunos Optimizadores de consultas de DBMS modifican su consulta para que sea más eficiente, por lo que, dependiendo del DBMS que utilice, probablemente no debería importarle.