¿Por qué poner una cláusula WHERE vista exterior tiene desempeño terrible

Question

Digamos que usted tiene una visión:

CREATE VIEW dbo.v_SomeJoinedTables AS 
SELECT 
    a.date, 
    a.Col1, 
    b.Col2, 
    DENSE_RANK() 
     OVER(PARTITION BY a.date, a.Col2 ORDER BY a.Col3) as Something 
FROM a JOIN b on a.date = b.date 

He encontrado que el rendimiento de:

SELECT * 
FROM v_SomeJoinedTables 
WHERE date > '2011-01-01' 

es mucho peor que

SELECT *, 
    DENSE_RANK() 
    OVER(PARTITION BY a.date, a.Col2 ORDER BY a.Col3) as Something 
FROM a JOIN b ON a.date = b.date 
WHERE a.date > '2011-01-01' 

Estoy muy sorprendido de que el plan de consulta para estas dos declaraciones no sea el mismo.

También he intentado utilizar una función de tabla en línea, pero la consulta todavía tarda 100-1000 veces más que el código donde copio y pego la lógica de vista.

¿Alguna idea?

Answer 1

Se llama "Predicate pushing" alias filtrado diferido.

SQL Server no siempre se da cuenta de que DONDE se puede aplicar "antes", dentro de la vista de manera efectiva.

Se ha mitigado en SQL Server 2008 para que funcione más de lo esperado

Answer 2

No soy un experto en SQL, por lo que puede ser rechazado por mi tontería, pero supongo que en el primer caso SQL obtiene los resultados de la vista completa antes de aplicar el predicado en la cláusula WHERE . Por lo tanto, cuando consulta la vista, selecciona todos los registros, los pone en la memoria y luego aplica el filtro de fecha después de que finaliza.

Esto parece similar a la búsqueda de todo el conjunto de datos especificado en sus uniones antes de aplicar el filtro en el WHERE (la lección aquí es que debe aplicar predicados en su cláusula ON cuando sea posible).

A menos que las vistas se traten de manera diferente de alguna manera.

Answer 3

Como solución alternativa, sugeriría usar una función en lugar de una vista para poder pasar el parámetro de datos.

Answer 4

Técnicamente, no está comparando entre las mismas sentencias de SQL. Su vista indica que devuelve a.date, a.Col1, b.Col2, más su función DENSE_RANK(). En su consulta sin la vista, devuelve todas las columnas.

Al principio, puede pensar que devolver todas las columnas sería peor. Pero es difícil determinar cuál sería mejor sin saber cómo se ve la estructura de la tabla, incluidos los índices.

¿Ha comparado los planes de consulta para cada declaración?

Answer 5

la sintaxis OVER() era nueva en SS2005 y aparentemente no está bien integrada en el optimizador. Te sugiero que pruebes una expresión más tradicional? Probablemente NO sea una expresión si te preocupa la optimización.

http://www.sqlteam.com/article/sql-sever-2005-using-over-with-aggregate-functions

O, mejor, ser un poco más familiarizados con el perfilador - la vista debe ser corregible.