Diferencia de rendimiento entre paso con variables y sql dinámico

Una pregunta sobre una consulta que me está volviendo tarumba: tengo
una consulta que hace cosas muy raras, después de muchas pruebas me di
cuenta de que si ejecutaba esta consulta en el Query Analizer todo iba de
perlas:

SELECT TOP 1 a, b
FROM Test
WHERE ((a < 'f0898153-0ad8-4752-a7ac-0000fb8208e2') OR
(a = 'f0898153-0ad8-4752-a7ac-0000fb8208e2' AND b < 151872))
ORDER BY a DESC, b DESC

sin embargo si ejecuto tal y como se ejecuta en realidad, con parámetros
el rendimiento pasa de ser instantáneo a tardar algo más de 30 segundos

declare @a uniqueidentifier
declare @b numeric(18,0)

set @a = 'f0898153-0ad8-4752-a7ac-0000fb8208e2'
set @b = 151872

SELECT TOP 1 a, b
FROM Test
WHERE ((a < @a) OR (a = @a AND b < @b))
ORDER BY a DESC, b DESC

Viendo los planes de ejecución se ve que en el primer caso hace una
búsqueda en el índice y en segundo un scan.

Una forma de arreglarlo ha sido dividir la consulta de esta forma:

SELECT TOP 1 *
FROM
(
SELECT a, b
FROM Test
WHERE a < @a
union
SELECT a, bFROM Test
WHERE a = @n AND b < @d
) lala ORDER BY a DESC, b DESC

Como la condición es un OR se divide así sin mayor problema, sin embargo
no me parece normal tener que hacer este apaño.

¿Alguien tiene alguna sugerencia de lo que puede estar pasando?

Muchas gracias

"Maxi" escribió en el mensaje
news:O9$r$

Hola, podrias pasarnos los planes de ejecucion? todo esto lo estas
ejecutando desde el QA?

La respuesta a la segunda pregunta es que si, todo esto son pruebas
desde el QA. Los planes de ejecución los adjunto en dos bonitos ficheros.
El resultado de ambas consultas es el mismo, menos en el tema del tiempo
claro...

Muchísimas gracias por todo.

Salu2
Maxi


"Tako" escribió en el mensaje
news:

Una pregunta sobre una consulta que me está volviendo tarumba: tengo
una consulta que hace cosas muy raras, después de muchas pruebas me di
cuenta de que si ejecutaba esta consulta en el Query Analizer todo iba
de
perlas:

SELECT TOP 1 a, b
FROM Test
WHERE ((a < 'f0898153-0ad8-4752-a7ac-0000fb8208e2') OR
(a = 'f0898153-0ad8-4752-a7ac-0000fb8208e2' AND b < 151872))
ORDER BY a DESC, b DESC

sin embargo si ejecuto tal y como se ejecuta en realidad, con parámetros
el rendimiento pasa de ser instantáneo a tardar algo más de 30 segundos

declare @a uniqueidentifier
declare @b numeric(18,0)

set @a = 'f0898153-0ad8-4752-a7ac-0000fb8208e2'
set @b = 151872

SELECT TOP 1 a, b
FROM Test
WHERE ((a < @a) OR (a = @a AND b < @b))
ORDER BY a DESC, b DESC

Viendo los planes de ejecución se ve que en el primer caso hace una
búsqueda en el índice y en segundo un scan.

Una forma de arreglarlo ha sido dividir la consulta de esta forma:

SELECT TOP 1 *
FROM
(
SELECT a, b
FROM Test
WHERE a < @a
union
SELECT a, bFROM Test
WHERE a = @n AND b < @d
) lala ORDER BY a DESC, b DESC

Como la condición es un OR se divide así sin mayor problema, sin embargo
no me parece normal tener que hacer este apaño.

¿Alguien tiene alguna sugerencia de lo que puede estar pasando?

Muchas gracias

Hola, que interesante :-S

Me dirias que Service Pack tienes?

Salu2
Maxi


"Tako" escribió en el mensaje
news:

"Maxi" escribió en el mensaje
news:O9$r$

Hola, podrias pasarnos los planes de ejecucion? todo esto lo estas
ejecutando desde el QA?

"Maxi" escribió en el mensaje
news:ODENj$
> Hola, que interesante :-S
>
> Me dirias que Service Pack tienes?
>

Claro, el SP es el 4 (8.0.2039)

Si te interesa pregunte al grupo ingles y me contestaron esto:

Por lo visto se llama "parameter Sniffing" y debe de ser algo

De momento yo lo he solucionado sustituyendo las llamadas con parámetros

llamadas con los parámetros "incrustados" en el SQL, como el "asuntillo"
sucedía en una parte en concreto y las llamadas son todas llamadas de SQL
dinámico (el jefe obliga) no ha habido mayor problema.

Muchas gracias por todo.

>
> Salu2
> Maxi
>
>
> "Tako" escribió en el mensaje
> news:
>>
>> "Maxi" escribió en el mensaje
>> news:O9$r$
>>> Hola, podrias pasarnos los planes de ejecucion? todo esto lo estas
>>> ejecutando desde el QA?
>>>
>>