sql - query - Seleccione la orden de evaluación "where clause"
sql server improve performance (7)
En Sql Server 2005 cuando tengo múltiples parámetros, ¿tengo la garantía de que el orden de evaluación siempre será de izquierda a derecha?
Usando un ejemplo:
select a from table where c=1 and d=2
En esta consulta, si la condición "c = 1" falla, ¿nunca se evaluará la condición "d = 2"?
PS- "c" es una columna indexada entera, d es una columna varchar grande y no indexable que requiere una exploración de tabla completa
actualización Estaba tratando de evitar realizar dos consultas o declaraciones condicionales, solo necesito algo como: si falla la "condición c" hay una manera de evitar realizar la pesada "condición d", ya que no es necesaria en mi caso.
El cortocircuito se realiza cuando la condición a la que nos referimos solo incluye literales o constantes. Entonces, por ejemplo, digamos que tenemos una tabla TableA que tiene una columna num con todos los números positivos del 1 al 10 y luego si escribo esta consulta.
Seleccione num desde TableA WHERE TableA.num <0 AND 1/0 = 10.
Se producirá un error.
¿El compilador es lo suficientemente inteligente como para determinar que mi segunda cláusula consta de constantes, por lo que debe evaluar eso antes de la cláusula de evaluación, que requiere cualquier escaneo desde la tabla o el índice?
El optimizador de consultas de MS SQL Server produce un cortocircuito, sí. Garantizado
Ejecuta esto:
select 1 where 1 = 0 and 1 / 0 = 10
Funcionará correctamente y no generará errores aunque esté dividiendo por cero porque el optimizador de consultas evaluará en cortocircuito la cláusula where. Esto tiene implicaciones para cualquier cláusula where donde estés "y" -ing y una de las partes sea una constante.
No hay garantías para el orden de evaluación. El optimizador intentará encontrar la forma más eficiente de ejecutar la consulta, utilizando la información disponible.
En su caso, dado que c está indexado y d no, el optimizador debe buscar en el índice todas las filas que coincidan con el predicado en c, luego recuperar esas filas de los datos de la tabla para evaluar el predicado en d.
Sin embargo, si determina que el índice de c no es muy selectivo (aunque no en su ejemplo, una columna de género rara vez se indexa), puede decidir realizar el escaneo de tabla de todos modos.
Para determinar el orden de ejecución, debe obtener un plan de explicación para su consulta. Sin embargo, tenga en cuenta que ese plan puede cambiar dependiendo de lo que el optimizador crea que es la mejor consulta en este momento.
Puede ver el plan de ejecución de la consulta y determinar qué está tratando de hacer realmente. Creo que se supone que el motor de consultas de SQL Server está haciendo este tipo de escaneo y lo traducirá inteligentemente en operaciones. Al igual que, si haces "caro-op Y falso", se evaluará rápidamente como falso.
Por lo que he aprendido, lo que escribes es (y puede ser) diferente de lo que realmente se ejecuta. Simplemente le está diciendo al servidor qué tipo de resultados espera. Cómo se obtiene la respuesta no se correlaciona de izquierda a derecha del código que proporciona.
SQL Server generará un plan optimizado para cada declaración que ejecute. No tiene que pedir su cláusula Where para obtener ese beneficio. El único garuntee que tienes es que ejecutará las declaraciones en orden, así:
SELECT A FROM B WHERE C
SELECT D FROM E WHERE F
correrá la primera línea antes del segundo.
Si quiere asegurarse de que puede verificar el plan de ejecución de consultas . El plan de ejecución que MSSQL crea / optimiza es lo suficientemente inteligente como para verificar la columna indexada antes de una columna varchar.
Una forma de controlar el orden de evaluación es con la expresión CASE.
[Editar]
La opinión popular que estaba tratando de expresar fue:
No puede depender del orden de evaluación de expresión para cosas como "DÓNDE O", ya que el optimizador puede elegir un plan que evalúe el segundo predicado antes del primero. Pero el orden de evaluación de las expresiones en una sentencia CASE es fijo, por lo que puede depender de la evaluación determinista de cortocircuitos de una sentencia CASE.
Se vuelve un poco más complicado que eso, como se explica en el siguiente sitio: