Eficiencia en Performance

Maxi,

Si, en la version 2, sql server siempre elige hacer un scan del indice, al
parecer el tipo de comparacion:

...
where orderid = case when @par1 = 0 then orderid else @par1 end

no es considerado un argumento de busqueda y por lo tanto, al tener un
indice asociado, decide hacer un scan del indice. Lo mismo pasa con
comparaciones tipo:

...
where orderid = @orderid or @orderid is null

...
where orderid = coalesce(@orderid, orderid)

... where datediff(orderdate, @startdate) > 15

claro, tambien depende de los indices que se tengan, de la selectividad de
la data, etc. Todo esto esta bien explicado en el articulo asociado al link
que adjunte anteriormente. Se lo recomiendo leer a todos, es una joya. Aca
pongo un link a otro articulo que habla sobre los argumentos de busqueda.

Transact-SQL Query
SQL Server Performance Tuning Tips
http://www.sql-server-performance.c...ct_sql.asp


AMB

"MAXI" wrote:

Un tema, en el query 1 veo que se ejecutan ambos y en el query 2 solo
siempre 1, si esto es asi habria que ver a grandes registros a la larga cual
es mas eficiente, parece ser el 1 porque hace en uno de sus querys un seek
pero en el otro siempre esta haciendo un scan ya que hace ambos por lo visto
:(


Me queda la duda :S



Maxi
Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)



"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Cuando uso la version 2, sql server decide hacer un scan del indice cuando
> no pasas el valor (logico, queremos todas las filas) o cuando le pasas el
> valor porque queremos una fila especifica. Esto no pasa con la version 1,
> sql
> server hace un scan del indice cuando no pasamos un valor y hace un index
> seek cuando pasamos un valor especifico. Quizas en una tabla como
> [orders],
> que contiene 830 filas, no se note la diferencia entre hacer un seek a un
> scan, pero en una tabla con un numero mayor si se veria. Puedes correr el
> script que adjunto y chequear los planes de ejecucion.
>
> use northwind
> go
>
> create procedure dbo.proc1
> @par1 int = 0
> as
> set nocount on
>
> if @par1 = 0
> select * from orders
> else
> select * from orders where orderid = @par1
>
> return @@error
> go
>
> create procedure dbo.proc2
> @par1 int = 0
> as
> set nocount on
>
> select * from orders where orderid = case when @par1 = 0 then orderid else
> @par1 end
>
> return @@error
> go
>
> set statistics profile on
> go
>
> dbcc freeproccache
> exec proc1
> go
>
> dbcc freeproccache
> exec proc1 10250
> go
>
> dbcc freeproccache
> exec proc2
> go
> dbcc freeproccache
> exec proc2 10250
> go
>
> set statistics profile off
> go
>
> drop procedure proc1, proc2
> go
>
>
> AMB
>
> "MAXI" wrote:
>
>> Hola, mi opinion que la opcion 2 es mas prolija y no creo que disminuya
>> la
>> performance
>>
>>
>>
>> Maxi
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>>
>>
>> "Eduardo" escribió en el mensaje
>> news:060101c52fc1$8109bda0$
>> Hola a todos. Tengo una pequeña preguntita a ver que
>> opinan uds. al respecto.
>> En un StoreProcedure que recibe parametros que es más
>> eficiente, verificar los datos de los parametros y
>> bifurcar con IF o verificarlos en la condición del SELECT.
>>
>> Por ejemplo,
>>
>> CREATE PROCEDURE dbo.Store1
>> @IdValor INT = 0
>> AS
>> IF @IdValor = 0
>> SELECT * FROM TIPOS
>> ELSE
>> SELECT * FROM TIPOS WHERE IdValor = @IdValor
>> GO
>> *-*-*-*-*-*
>> Será más eficiente que:
>>
>> CREATE PROCEDURE dbo.Store1
>> @IdValor INT = 0
>> AS
>> SELECT * FROM TIPOS WHERE IdValor > >> CASE WHEN @IdValor = THEN IdValor ELSE @IdValor END
>> GO
>>
>>
>> Me gustaría conocer cual es su opinión al respecto.
>> Saludos Cordiales y gracias por los comentarios
>>
>>
>>

Gracias Ale, pero aun no me saco la duda del IF donde veo que el analizador
ejecuta ambos, o por lo menos eso es lo que parece, podes decirme si esto es
asi?



Maxi
Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)



"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

Si, en la version 2, sql server siempre elige hacer un scan del indice, al
parecer el tipo de comparacion:

...
where orderid = case when @par1 = 0 then orderid else @par1 end

no es considerado un argumento de busqueda y por lo tanto, al tener un
indice asociado, decide hacer un scan del indice. Lo mismo pasa con
comparaciones tipo:

...
where orderid = @orderid or @orderid is null

...
where orderid = coalesce(@orderid, orderid)

... where datediff(orderdate, @startdate) > 15

claro, tambien depende de los indices que se tengan, de la selectividad de
la data, etc. Todo esto esta bien explicado en el articulo asociado al
link
que adjunte anteriormente. Se lo recomiendo leer a todos, es una joya. Aca
pongo un link a otro articulo que habla sobre los argumentos de busqueda.

Transact-SQL Query
SQL Server Performance Tuning Tips
http://www.sql-server-performance.c...ct_sql.asp


AMB

"MAXI" wrote:

Un tema, en el query 1 veo que se ejecutan ambos y en el query 2 solo
siempre 1, si esto es asi habria que ver a grandes registros a la larga
cual
es mas eficiente, parece ser el 1 porque hace en uno de sus querys un
seek
pero en el otro siempre esta haciendo un scan ya que hace ambos por lo
visto
:(


Me queda la duda :S



Maxi
Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)



"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Cuando uso la version 2, sql server decide hacer un scan del indice
> cuando
> no pasas el valor (logico, queremos todas las filas) o cuando le pasas
> el
> valor porque queremos una fila especifica. Esto no pasa con la version
> 1,
> sql
> server hace un scan del indice cuando no pasamos un valor y hace un
> index
> seek cuando pasamos un valor especifico. Quizas en una tabla como
> [orders],
> que contiene 830 filas, no se note la diferencia entre hacer un seek a
> un
> scan, pero en una tabla con un numero mayor si se veria. Puedes correr
> el
> script que adjunto y chequear los planes de ejecucion.
>
> use northwind
> go
>
> create procedure dbo.proc1
> @par1 int = 0
> as
> set nocount on
>
> if @par1 = 0
> select * from orders
> else
> select * from orders where orderid = @par1
>
> return @@error
> go
>
> create procedure dbo.proc2
> @par1 int = 0
> as
> set nocount on
>
> select * from orders where orderid = case when @par1 = 0 then orderid
> else
> @par1 end
>
> return @@error
> go
>
> set statistics profile on
> go
>
> dbcc freeproccache
> exec proc1
> go
>
> dbcc freeproccache
> exec proc1 10250
> go
>
> dbcc freeproccache
> exec proc2
> go
> dbcc freeproccache
> exec proc2 10250
> go
>
> set statistics profile off
> go
>
> drop procedure proc1, proc2
> go
>
>
> AMB
>
> "MAXI" wrote:
>
>> Hola, mi opinion que la opcion 2 es mas prolija y no creo que
>> disminuya
>> la
>> performance
>>
>>
>>
>> Maxi
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>>
>>
>> "Eduardo" escribió en el mensaje
>> news:060101c52fc1$8109bda0$
>> Hola a todos. Tengo una pequeña preguntita a ver que
>> opinan uds. al respecto.
>> En un StoreProcedure que recibe parametros que es más
>> eficiente, verificar los datos de los parametros y
>> bifurcar con IF o verificarlos en la condición del SELECT.
>>
>> Por ejemplo,
>>
>> CREATE PROCEDURE dbo.Store1
>> @IdValor INT = 0
>> AS
>> IF @IdValor = 0
>> SELECT * FROM TIPOS
>> ELSE
>> SELECT * FROM TIPOS WHERE IdValor = @IdValor
>> GO
>> *-*-*-*-*-*
>> Será más eficiente que:
>>
>> CREATE PROCEDURE dbo.Store1
>> @IdValor INT = 0
>> AS
>> SELECT * FROM TIPOS WHERE IdValor >> >> CASE WHEN @IdValor = THEN IdValor ELSE @IdValor END
>> GO
>>
>>
>> Me gustaría conocer cual es su opinión al respecto.
>> Saludos Cordiales y gracias por los comentarios
>>
>>
>>