Optimizar where

11/04/2007 - 16:18 por Matias | Informe spam
Hola gente, tengo una duda; en una tabla que tengo muchos registos y en el
where se debe traer todos menos uno en particular, que es mas eficiente?:

WHERE codigo NOT IN ('PEPE')
o
WHERE codigo <> 'PEPE'

Me parece que la primera, estuve viendo el plan de ejecucion para ambas
sentecias, pero me arroja iguales resultados para las dos.

Gracias por su tiempo.
Saludos desde Córdoba(Arg.)

Preguntas similare

Leer las respuestas

#6 Antonio Ortiz
11/04/2007 - 23:00 | Informe spam
Y si el codigo Pepe existe muchas veces, no supone una ventaja la existencia
de un indice?

saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"Javier Loria" escribió en el mensaje
news:
Hola Matias:
Muy rara vez habrá diferencia entre estas dos setencias, sin importar
como las interprete el SQL, y la razón la das cuando dices que debe traer
todos menos uno en particular.
Básicamente el servidor leera siempre todos, y luego aplicara la
condicion, por lo que nunca usara un indice para filtrar los datos :(
Los indices y por ende la mejora significativa en desempeño, se
utilizan solamente cuando las consultas son selectivas.
En algunas ocasiones el motor relacional, normaliza el SQL para hacerlo
mas eficiente, pero no es este el caso.
Saludos,


Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

"Matias" wrote in message
news:%
Hola gente, tengo una duda; en una tabla que tengo muchos registos y en
el
where se debe traer todos menos uno en particular, que es mas eficiente?:

WHERE codigo NOT IN ('PEPE')
o
WHERE codigo <> 'PEPE'

Me parece que la primera, estuve viendo el plan de ejecucion para ambas
sentecias, pero me arroja iguales resultados para las dos.

Gracias por su tiempo.
Saludos desde Córdoba(Arg.)





Respuesta Responder a este mensaje
#7 Javier Loria
12/04/2007 - 01:51 | Informe spam
Hola Antonio:
Ninguna :( y si algunas desventajas.
Si el indice no es selectivo, o sea si la condicion no filtra
sustancialmente el numero de registros, entonces se descarta el indice y no
se usa.
Un ejemplo para ver si se entiende.
Asume que eres un persona encargada de hacer censos de una ciudad de
100,000 habitantes y te piden hacer un questionario solo a los hombres.
Asume que tienes una lista en la oficina de todos los habitantes con su
nombre, sexo y direccion, pero no puedes remover la lista de la oficina por
razones de seguridad. Asumimos que todos habitan en su casa y siempre los
encuentras ahi.
Que será mejor, leer la dirección del primer hombre en la lista, ir
hacer el cuestionario a su casa, y luego volver a la oficina de censos a
leer quien es el siguiente hombre, y asi sucesivamente hasta terminar la
lista; O, ir y recorrer toda las calles secuencialment, y hacer el
questionario a todos los hombres que nos encontramos descartando a las
mujeres. Es obvio que el segundo caso es mucho mas eficiente.
Ese mismo escenario lo enfrenta SQL cuando usa un indice, es con
frequencia demasiado caro buscar en la estructura del indice la referencia a
un dato, para luego para ir brincando de una lado a lado en la tabla
ordenada en uns estructura para recopilar filas que cumplen la condicion. En
esos casos el servidor encuentra mucho mas rápido leer toda la tabla y
filtrar las filas que no cumplen la condicion, sin usar el indice.
Una columna que no es distintiva (que no tiene miles de datos
diferentes) y no separa unas filas de otras, es inutil como indice. Sin
importar cuantas veces se lea el dato.
Por otra parte, si en este ejemplo nos pidieran un questionario a todos
los Antonios, y solamente hay 10 Antonios en la población, si usariamos el
censo para buscar las direcciones de los Antonios ha hacerles el
questionario. Esto es porque el indice Nombre es selectivo (0.01%), mientras
que el Sexo no lo es (50%).
La selectividad de una columna el servidor de SQL la mantiene en algo
llamada Estadisticas, que le dan al optimizador de consultas una idea de si
vale la pena o no usar una estrategia u otra.
Espero haberme explicado adecuadamente,
Un saludo,


Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

"Antonio Ortiz" wrote in message
news:

Y si el codigo Pepe existe muchas veces, no supone una ventaja la
existencia de un indice?

saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"Javier Loria" escribió en el mensaje
news:
Hola Matias:
Muy rara vez habrá diferencia entre estas dos setencias, sin importar
como las interprete el SQL, y la razón la das cuando dices que debe traer
todos menos uno en particular.
Básicamente el servidor leera siempre todos, y luego aplicara la
condicion, por lo que nunca usara un indice para filtrar los datos :(
Los indices y por ende la mejora significativa en desempeño, se
utilizan solamente cuando las consultas son selectivas.
En algunas ocasiones el motor relacional, normaliza el SQL para
hacerlo mas eficiente, pero no es este el caso.
Saludos,


Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

"Matias" wrote in message
news:%
Hola gente, tengo una duda; en una tabla que tengo muchos registos y en
el
where se debe traer todos menos uno en particular, que es mas
eficiente?:

WHERE codigo NOT IN ('PEPE')
o
WHERE codigo <> 'PEPE'

Me parece que la primera, estuve viendo el plan de ejecucion para ambas
sentecias, pero me arroja iguales resultados para las dos.

Gracias por su tiempo.
Saludos desde Córdoba(Arg.)









Respuesta Responder a este mensaje
#8 Antonio Ortiz
12/04/2007 - 04:22 | Informe spam
muy interesante, gracias por amplia la explicacion.


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"Javier Loria" escribió en el mensaje
news:
Hola Antonio:
Ninguna :( y si algunas desventajas.
Si el indice no es selectivo, o sea si la condicion no filtra
sustancialmente el numero de registros, entonces se descarta el indice y
no se usa.
Un ejemplo para ver si se entiende.
Asume que eres un persona encargada de hacer censos de una ciudad de
100,000 habitantes y te piden hacer un questionario solo a los hombres.
Asume que tienes una lista en la oficina de todos los habitantes con su
nombre, sexo y direccion, pero no puedes remover la lista de la oficina
por razones de seguridad. Asumimos que todos habitan en su casa y siempre
los encuentras ahi.
Que será mejor, leer la dirección del primer hombre en la lista, ir
hacer el cuestionario a su casa, y luego volver a la oficina de censos a
leer quien es el siguiente hombre, y asi sucesivamente hasta terminar la
lista; O, ir y recorrer toda las calles secuencialment, y hacer el
questionario a todos los hombres que nos encontramos descartando a las
mujeres. Es obvio que el segundo caso es mucho mas eficiente.
Ese mismo escenario lo enfrenta SQL cuando usa un indice, es con
frequencia demasiado caro buscar en la estructura del indice la referencia
a un dato, para luego para ir brincando de una lado a lado en la tabla
ordenada en uns estructura para recopilar filas que cumplen la condicion.
En esos casos el servidor encuentra mucho mas rápido leer toda la tabla y
filtrar las filas que no cumplen la condicion, sin usar el indice.
Una columna que no es distintiva (que no tiene miles de datos
diferentes) y no separa unas filas de otras, es inutil como indice. Sin
importar cuantas veces se lea el dato.
Por otra parte, si en este ejemplo nos pidieran un questionario a todos
los Antonios, y solamente hay 10 Antonios en la población, si usariamos el
censo para buscar las direcciones de los Antonios ha hacerles el
questionario. Esto es porque el indice Nombre es selectivo (0.01%),
mientras que el Sexo no lo es (50%).
La selectividad de una columna el servidor de SQL la mantiene en algo
llamada Estadisticas, que le dan al optimizador de consultas una idea de
si vale la pena o no usar una estrategia u otra.
Espero haberme explicado adecuadamente,
Un saludo,


Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

"Antonio Ortiz" wrote in message
news:

Y si el codigo Pepe existe muchas veces, no supone una ventaja la
existencia de un indice?

saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"Javier Loria" escribió en el mensaje
news:
Hola Matias:
Muy rara vez habrá diferencia entre estas dos setencias, sin importar
como las interprete el SQL, y la razón la das cuando dices que debe
traer todos menos uno en particular.
Básicamente el servidor leera siempre todos, y luego aplicara la
condicion, por lo que nunca usara un indice para filtrar los datos :(
Los indices y por ende la mejora significativa en desempeño, se
utilizan solamente cuando las consultas son selectivas.
En algunas ocasiones el motor relacional, normaliza el SQL para
hacerlo mas eficiente, pero no es este el caso.
Saludos,


Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

"Matias" wrote in message
news:%
Hola gente, tengo una duda; en una tabla que tengo muchos registos y en
el
where se debe traer todos menos uno en particular, que es mas
eficiente?:

WHERE codigo NOT IN ('PEPE')
o
WHERE codigo <> 'PEPE'

Me parece que la primera, estuve viendo el plan de ejecucion para ambas
sentecias, pero me arroja iguales resultados para las dos.

Gracias por su tiempo.
Saludos desde Córdoba(Arg.)












email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida