A veces, las consultas lentas se pueden solucionar modificando ligeramente la consulta. Un ejemplo de este tipo puede ilustrarse cuando se comparan múltiples valores en una cláusula WHERE utilizando el operador OR o IN. A menudo, un OR puede causar un escaneo de índice o tabla, que puede no ser el plan de ejecución preferido en términos de consumo de E / S o velocidad general de consulta.
Muchas variables entran en juego cuando el optimizador de consultas crea un plan de ejecución. Estas variables incluyen muchas características de hardware, configuraciones de instancias, configuraciones de bases de datos, estadísticas (tabla, índice, autogeneradas), así como una forma de escribir una consulta. Aquí cambiamos la forma en que escribimos la solicitud. No importa cuán inesperado pueda parecer esto, incluso si dos consultas diferentes pueden devolver los mismos resultados, la ruta que siguen puede ser completamente diferente según el formato de la consulta.
UNION vs OR
Para la mayor parte de mi experiencia con SQL Server, OR suele ser menos eficiente que UNION. Lo que generalmente sucede con OR es que a menudo causa un escaneo. A veces, esta puede ser la mejor manera para algunos casos, y lo dejaré como un artículo separado, pero en general, he descubierto que cuando se ve afectado un gran número de entradas, esta es la razón principal de la desaceleración. Entonces, comencemos nuestra comparación.
Aquí está nuestra declaración OR:
SELECT SalesOrderID, * FROM sales.SalesOrderDetail WHERE ProductID = 750 OR ProductID = 953
A partir de este plan de ejecución, vemos que estamos escaneando 121,000 filas. (No puede ver el número de filas, pero lo es).
Ahora ejecutamos la misma consulta, pero escrita usando UNION en lugar de OR:
SELECT [SalesOrderID], * FROM sales.SalesOrderDetail WHERE ProductID = 750 UNION SELECT [SalesOrderID], * FROM sales.SalesOrderDetail WHERE ProductID = 953
Aquí vemos dos ramas de operaciones. Una rama afecta a 358 líneas y las otras 346 líneas. Se encuentra que ambas ramas realizan una operación de concatenación que combina ambos conjuntos de resultados. Tenemos dos búsquedas separadas, pero también tenemos una búsqueda clave para obtener la lista SELECT requerida. Esto no fue necesario para la operación de escaneo, porque todavía afectamos a todas las líneas en la operación de escaneo, por lo que los datos se obtuvieron durante el escaneo, no después. Esto se debe al índice y las filas que necesitamos, no a UNION u OR. Sin embargo, diré que seleccionar también es un factor en la elección de una búsqueda vs exploración, pero ignoraremos esto en este artículo.
Explicación
Por qué UNION provoca más búsquedas en lugar de escaneos, porque cada operación debe cumplir un cierto requisito de selectividad para calificar para una búsqueda. (La selectividad es la unicidad de una columna filtrada particular). O ocurre en una sola operación, de modo que cuando la selectividad para cada columna se combina y excede un cierto porcentaje, el escaneo se considera más eficiente.
Dado que UNION realiza una operación separada para cada operador de manera predeterminada, la selectividad de cada columna no se combina, lo que le brinda una mejor oportunidad de realizar una búsqueda. Ahora, dado que UNION realiza dos operaciones, deben coincidir con sus conjuntos de resultados utilizando la operación de concatenación descrita anteriormente. Esto generalmente no es una operación costosa.
También se debe tener en cuenta que la cláusula OR funciona de la misma manera que la declaración IN.
Espero que este consejo te ayude. Creo que esto es muy valioso cuando se trabaja con sistemas que requieren una alta concurrencia.