Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

eficiencia entre decimal y entero

25/09/2003 - 23:31 por josenadim | Informe spam
Ayuda Hacer una pregunta
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
email Siga el debateRespuesta 8 respuestasRespuesta Tengo una respuesta
DRAGON AGE™: INQUISITION – Matadragones
 

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

Preguntas similares

 

Busqueda sugerida :