eficiencia entre decimal y entero

25/09/2003 - 23:31 por josenadim | Informe spam

Cordial saludo grupo; tengo dudas sobre un articulo, en el que no
encuentro diferencias de rendimento segun lo comentado en el sitio:
http://www.windowstimag.com/sqlmag/...uestas.htm

He realizado pruebas de rendimento sobre un millon de registros con un
valor x y no veo la mejora ,el articulo es el siguiente
**********************************************************
**********************************************************
P. Tengo una tabla con un tipo de datos decimal en un campo llamado
COD. Si emito una consulta con un filtro que pase un número, como por
ejemplo:

SELECT * FROM table1 WHERE COD = 123

SQL Server aplica una exploración de índice y de vuelve los datos muy
despacio. Sin embargo, si coloco un separador decimal tras el número,
como por ejemplo:

SELECT * FROM table1 WHERE COD = 123.

SQL Server aplica una búsqueda de índice y devuelve los resultados
mucho más deprisa. ¿Por qué el uso del separador decimal determina el
modo en que SQL Server maneja de la consulta?
R. Si no se utiliza un separador decimal al final del número, SQL
Server lo considera como un valor entero y necesita convertir los
datos para compararlos con el valor. Si se utiliza el separador
decimal, SQL Server considera correctamente que el valor es un dato de
tipo numérico, que es el tipo de los datos decimales, y puede aplicar
una búsqueda de índice, que en este caso es un método más rápido que
la exploración de índice.

Aqui estan hablando de una tabla sin indice Agrupado?,
mis tablas son de produccion con PK y el campo no es parte de la PK
aunque aqui hace index scan por indice no agrupado y luego busqueda
por marcador de indice agrupado(bookmark lookup).. sera
por eso que no encunetro la diferencia en performance???

el campo es parte de un indice no agrupado
Adicionalmente como tenemos varios campos decimales con precision de
cero preferiria pasarlos a numerico y ganar rendimento si en verdad
existe mejora. de nuevo gracias por sus opiones.

Jose Nadim

Siga el debate

8 respuestas

Tengo una respuesta

Preguntas similare

Diferencia entre Decimal y Numeric

Leer las respuestas

#1 Eladio Rincón

26/09/2003 - 00:32 | Informe spam

Hola,

respecto a la última parte del artículo, es erroneoahora mismo no recuerdo cuales eran las premisas para que una condición fuera argumento de búsqueda (técnicamente SARG -- de inglés search argument) en versiones anteriores de SQL Server, pero las condiciones en SQL Server 2000 son las siguiente:

<columna> <operador de inclusión> <constante o variable> o
<constante o variable> <operador de inclusión> <columna>

donde los operadores de inclusión son:
=, >, <, >=, <=, BETWEEN y LIKE con comidín al final ( del tipo <constante> + '%' )

puedes probar el siguiente script y verás que ambos planes de ejecución son los mismos:

create table test2
( id decimal (10,2) primary key,
valor char(1000) default 'aaa' )

declare @i decimal(10,2)
set @i = 0
while @i < 5000
begin
insert into test2 ( id ) values ( @i )
set @i = @i + 1
end

select *
from test2
where id = cast ( cast ( 12 as char (1000)) as integer )

select *
from test2
where id = 12.

select *
from test2
where id = 12

mi versión de SQL Server es:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 1)

Posiblemente el artículo se refiera a otra versión porque incluso entre service pack se mejora mucho el producto y el optimizador de consultas es una parte importante :-)

Eladio Rincón
SQL Server MVP
http://eladio.europe.webmatrixhosting.net

"Comparte lo que sabes, aprende lo que no sepas." FGG

"Jose Nadim" escribió en el mensaje news:

Cordial saludo grupo; tengo dudas sobre un articulo, en el que no
encuentro diferencias de rendimento segun lo comentado en el sitio:
http://www.windowstimag.com/sqlmag/...uestas.htm

He realizado pruebas de rendimento sobre un millon de registros con un
valor x y no veo la mejora ,el articulo es el siguiente
**********************************************************
**********************************************************
P. Tengo una tabla con un tipo de datos decimal en un campo llamado
COD. Si emito una consulta con un filtro que pase un número, como por
ejemplo:

SELECT * FROM table1 WHERE COD = 123

SQL Server aplica una exploración de índice y de vuelve los datos muy
despacio. Sin embargo, si coloco un separador decimal tras el número,
como por ejemplo:

SELECT * FROM table1 WHERE COD = 123.

SQL Server aplica una búsqueda de índice y devuelve los resultados
mucho más deprisa. ¿Por qué el uso del separador decimal determina el
modo en que SQL Server maneja de la consulta?
R. Si no se utiliza un separador decimal al final del número, SQL
Server lo considera como un valor entero y necesita convertir los
datos para compararlos con el valor. Si se utiliza el separador
decimal, SQL Server considera correctamente que el valor es un dato de
tipo numérico, que es el tipo de los datos decimales, y puede aplicar
una búsqueda de índice, que en este caso es un método más rápido que
la exploración de índice.

Aqui estan hablando de una tabla sin indice Agrupado?,
mis tablas son de produccion con PK y el campo no es parte de la PK
aunque aqui hace index scan por indice no agrupado y luego busqueda
por marcador de indice agrupado(bookmark lookup).. sera
por eso que no encunetro la diferencia en performance???

el campo es parte de un indice no agrupado
Adicionalmente como tenemos varios campos decimales con precision de
cero preferiria pasarlos a numerico y ganar rendimento si en verdad
existe mejora. de nuevo gracias por sus opiones.

Jose Nadim

Responder a este mensaje

#2 Miguel Egea

26/09/2003 - 09:13 | Informe spam

El artículo en cuestión es de 2001 y se refiere a SS 7.0 es por lo que las
optimizaciones no tiene tanto efecto.

Saludos Cordiales
=Miguel Egea
http://www.portalsql.com
Microsoft SQL-SERVER MVP.

¡Cuida el rendimiento! Evita los cursores
Brigada Anti-Cursores
==

"Eladio Rincón" escribió en el mensaje
news:
Hola,

respecto a la última parte del artículo, es erroneoahora mismo no recuerdo
cuales eran las premisas para que una condición fuera argumento de búsqueda
(técnicamente SARG -- de inglés search argument) en versiones anteriores de
SQL Server, pero las condiciones en SQL Server 2000 son las siguiente:

<columna> <operador de inclusión> <constante o variable> o
<constante o variable> <operador de inclusión> <columna>

donde los operadores de inclusión son:
=, >, <, >=, <=, BETWEEN y LIKE con comidín al final ( del tipo <constante>
+ '%' )

puedes probar el siguiente script y verás que ambos planes de ejecución son
los mismos:

create table test2
( id decimal (10,2) primary key,
valor char(1000) default 'aaa' )

declare @i decimal(10,2)
set @i = 0
while @i < 5000
begin
insert into test2 ( id ) values ( @i )
set @i = @i + 1
end

select *
from test2
where id = cast ( cast ( 12 as char (1000)) as integer )

select *
from test2
where id = 12.

select *
from test2
where id = 12

mi versión de SQL Server es:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 1)

Posiblemente el artículo se refiera a otra versión porque incluso entre
service pack se mejora mucho el producto y el optimizador de consultas es
una parte importante :-)

Eladio Rincón
SQL Server MVP
http://eladio.europe.webmatrixhosting.net

"Comparte lo que sabes, aprende lo que no sepas." FGG

"Jose Nadim" escribió en el mensaje
news:

Cordial saludo grupo; tengo dudas sobre un articulo, en el que no
encuentro diferencias de rendimento segun lo comentado en el sitio:

http://www.windowstimag.com/sqlmag/...spuestas.h
tm

He realizado pruebas de rendimento sobre un millon de registros con un
valor x y no veo la mejora ,el articulo es el siguiente
**********************************************************
**********************************************************
P. Tengo una tabla con un tipo de datos decimal en un campo llamado
COD. Si emito una consulta con un filtro que pase un número, como por
ejemplo:

SELECT * FROM table1 WHERE COD = 123

SQL Server aplica una exploración de índice y de vuelve los datos muy
despacio. Sin embargo, si coloco un separador decimal tras el número,
como por ejemplo:

SELECT * FROM table1 WHERE COD = 123.

SQL Server aplica una búsqueda de índice y devuelve los resultados
mucho más deprisa. ¿Por qué el uso del separador decimal determina el
modo en que SQL Server maneja de la consulta?
R. Si no se utiliza un separador decimal al final del número, SQL
Server lo considera como un valor entero y necesita convertir los
datos para compararlos con el valor. Si se utiliza el separador
decimal, SQL Server considera correctamente que el valor es un dato de
tipo numérico, que es el tipo de los datos decimales, y puede aplicar
una búsqueda de índice, que en este caso es un método más rápido que
la exploración de índice.

Aqui estan hablando de una tabla sin indice Agrupado?,
mis tablas son de produccion con PK y el campo no es parte de la PK
aunque aqui hace index scan por indice no agrupado y luego busqueda
por marcador de indice agrupado(bookmark lookup).. sera
por eso que no encunetro la diferencia en performance???

el campo es parte de un indice no agrupado
Adicionalmente como tenemos varios campos decimales con precision de
cero preferiria pasarlos a numerico y ganar rendimento si en verdad
existe mejora. de nuevo gracias por sus opiones.

Jose Nadim

Responder a este mensaje

#3 josenadim

26/09/2003 - 18:30 | Informe spam

gracias por sus respuestas contesto entre lineas

El artículo en cuestión es de 2001 y se refiere a SS 7.0 es por lo que las
optimizaciones no tiene tanto efecto.

Miguel ,en cuanto a la optimizacion sobre SS7 es especificamente sobre
este tema o sobre algun otro para SS7
me interesa lo de brigada anticursores ,los temas estan en el foro?

puedes probar el siguiente script y verás que ambos planes de ejecución son
los mismos:

Eladio ,si efectivamente los planes de ejecucion y el tiempo son
identicos.
Mi servidor es NT4 con SS7 spck4

mil gracias

Jose Nadim

Responder a este mensaje

#4 Eladio Rincón

27/09/2003 - 01:08 | Informe spam

Hola,

Eladio ,si efectivamente los planes de ejecucion y el tiempo son
identicos.
Mi servidor es NT4 con SS7 spck4

De hecho, la nomenclatura que puse en el mensaje es sacada de libro Inside SQL Server 2000; esta tarde he revisado Inside SQL Server 7.0, y las condiciones de los SARGs son las mismas; es posible que el artículo se refiera a la versión 6.5 de SQL Server, pero hasta que no vea el plan de ejecución sobre 6.5 no podría confirmartelo.

Por cierto, le he enviado un correo al editor de la revista para que rectifique el artículo porque como se entere R.Waymire se va a enfadar ;-)

Saludos,

Eladio Rincón
SQL Server MVP
http://eladio.europe.webmatrixhosting.net

"Comparte lo que sabes, aprende lo que no sepas." FGG

"Jose Nadim" escribió en el mensaje news:

gracias por sus respuestas contesto entre lineas
> El artículo en cuestión es de 2001 y se refiere a SS 7.0 es por lo que las
> optimizaciones no tiene tanto efecto.
Miguel ,en cuanto a la optimizacion sobre SS7 es especificamente sobre
este tema o sobre algun otro para SS7
me interesa lo de brigada anticursores ,los temas estan en el foro?

> puedes probar el siguiente script y verás que ambos planes de ejecución son
> los mismos:
Eladio ,si efectivamente los planes de ejecucion y el tiempo son
identicos.
Mi servidor es NT4 con SS7 spck4

mil gracias

Jose Nadim