Seleccione la orden de evaluación "where clause"

Question

En SQL Server 2005 cuando tengo múltiples parámetros, ¿tengo la garantía de que la orden de evaluación será siempre de izquierda a derecha?

Utilizando un ejemplo:

select a from table where c=1 and d=2

En esta consulta si el "c = 1" condición falla nunca se evaluó la condición "d = 2"?

PD- "c" es una columna entera en un índice, d es un gran varchar y la columna no indexable que requiere un escaneo completo de tabla

actualización yo estaba tratando de evitar la realización de dos consultas o sentencias condicionales, me Solo necesito algo como: si la "condición c" falla, hay una manera de evitar realizar la pesada "condición d", ya que no es necesaria en mi caso.

Answer 1

No hay garantías para la 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 en c no es muy selectivo (aunque no en su ejemplo, una columna de género rara vez se indexa), puede decidir hacer 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.

Answer 2

SQL Server generará un plan optimizado para cada instrucción que ejecuta. No tiene que pedir su cláusula Where para obtener ese beneficio. La única garuntee que tiene es que va a ejecutar instrucciones en orden para:

SELECT A FROM B WHERE C 
SELECT D FROM E WHERE F 

se ejecutará la primera línea antes de la segunda.

Answer 3

Puede ver el plan de ejecución de la consulta y determinar lo que realmente está tratando de hacer. 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 escribe 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.

Answer 4

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 era:

Usted no puede depender de orden de evaluación expresión para cosas como “DONDE O”, ya que el optimizador puede elegir un plan que evalúa el segundo predicado antes que el primero. Pero el orden 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 pone un poco más complicado que eso, como se explica en el siguiente sitio web:

http://blogs.msdn.com/b/bartd/archive/2011/03/03/don-t-depend-on-expression-short-circuiting-in-t-sql-not-even-with-case.aspx

Answer 5

Si usted quiere estar seguro de que puede comprobar la Query Execution Plan. El plan de ejecución que MSSQL crea/optimiza es lo suficientemente inteligente como para verificar la columna indexada antes de una columna varchar.

Answer 6

El optimizador de consultas de MS SQL Server produce un cortocircuito, sí. Garantizado

Ejecutar este:

select 1 where 1 = 0 and 1/0 = 10 

se ejecutará bien y no de error aunque estás dividiendo por cero porque el optimizador de consultas cortocircuito evaluar 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.

Answer 7

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.

Seleccionar num de la Tabla A DONDE TableA.num < 0 Y = 1/0 10.

que dará lugar a error.

¿El compilador es lo suficientemente inteligente como para determinar que mi segunda cláusula consta de constantes, por lo que debería evaluar eso antes de la cláusula de evaluación que requiere cualquier exploración desde la tabla o el índice?