Entre mas campos hayan en el WHERE mas rapida es la consulta?

[mafima]

buenas queria preguntarles si entre mas campos restrictivos hayan en la clausula WHERE mas rapida es la consulta o es mas lenta.

gracias!

[a2a2]

Pues supongo que dependerá del numero de resultados que cumplan la(s) condición(es).
Pero a igualdal de resultados imagino que cuantos más "where" peor, porque tiene más cosas que comprobar y filtrar.

[matanga]

Hola,

En primer lugar, la cantidad de condiciones que existan en el where tiene que ver con la informacion que se quiere obtener de la base de datos y no con la velocidad de la consulta, es un cuestion de logica de conjuntos (intersecciones, uniones, nulo o vacio, diferente de, igual que, etc), pero si tiene un impacto en la velocidad, la idea es comentar que se puede hacer al respecto.

Rows: es la cantidad de registros que cumplen con las condiciones.
Bytes: es el peso en bytes de los registros que cumplen con las condiciones.
Cost: es el costo de la consulta segun el optimizador.

En el primer caso tengo un solo filtro, status = 'VALID'

Código:

SQL> explain plan for
  2  select object_name from t1 where status = 'VALID';

--------------------------------------------------------------------------
| Id  | Operation	  | Name | Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	 | 19680 |   615K|   129   (4)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| T1	 | 19680 |   615K|   129   (4)| 00:00:02 |
--------------------------------------------------------------------------

En el segundo caso tengo dos condiciones, donde mantengo la primera y agrego una mas, en este caso la cantidad de filas se fue a poco mas de la mitad pero tuve un incremento en el costo de cpu para obtener los datos, hasta aqui se podria intuir el trabajo adicional de evaluar una segunda condicion.

Código:

SQL> explain plan for
  2   select object_name from t1 where status = 'VALID' and temporary = 'N';

--------------------------------------------------------------------------
| Id  | Operation	  | Name | Rows  | Bytes | Cost (%CPU)| Time	 |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |	 |  9840 |   326K|   130   (5)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| T1	 |  9840 |   326K|   130   (5)| 00:00:02 |
--------------------------------------------------------------------------

En el ultimo caso, agrego una tercera condicion, manteniendo las primeras dos, pero el costo de cpu se fue al minimo, esto es porque el acceso a la tabla se hace a traves de un indice creado sobre el campo object_id.

Código:

SQL> explain plan for
  2   select object_name from t1 where status = 'VALID' and temporary = 'N' and object_id = 15;

-------------------------------------------------------------------------------------------
| Id  | Operation		    | Name	  | Rows  | Bytes | Cost (%CPU)| Time	  |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |		  |	1 |    39 |	2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T1	  |	1 |    39 |	2   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN	    | IND_T1_O_ID |	1 |	  |	1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------

En conclusion, no es tanto la cantidad de condiciones del where, si no, como accede la base de datos a las filas de las tablas. Lo que hay que tener es un buen modelo de datos con sus respectivos indices, y dejar los filtros de las consultas para el modelo logico.

Saludos

[nohemibaac]

entre mas where tienes, es mas especifica la consulta y mas rápida, yo he comprobado eso tanto en oracle,sql y access

[mafima]

Entiendo sus puntos de vistas, ahora profundizo un poco mas.

Sucede que en una tabla de usuario necesito hacer una busqueda de usuarios por pais y usuarios por region ( son dos ID unicos )

entonces tengo dos opciones crear un indice para ID_regio y crear otro indice para ID_pais

o crear un solo indice para ambos agregando ambos campos al indice.

ahora bien desde el pundo te vista de los insert y los update resulta mas optimo hacer un solo indice, pero queria saber como se comportan las consultas:

si uso la segunda opcion el where para buscar regiones tendria que ser: where ID_pais=ID_del_pais_buscado AND ID_region=ID_region_buscada

es decir dos condiciones para el where. ( aunque es usando un indice)

si estuvieran en mi lugar que harian ustedes?

[seyko]

dependerá de que BD utilices y como gestiona dicha BD los indices simples y compuestos.

Un saludo

[seyko]

Iniciado por nohemibaac

entre mas where tienes, es mas especifica la consulta y mas rápida, yo he comprobado eso tanto en oracle,sql y access

Prodrías mostrar esa comprobación???

[nohemibaac]

Corriendo una consulta, en un caso de oracle, tengo una tabla con 254,512 registros, tenia q hacer inner join con esa tabla a otras 4 más en 2 diferentes tablespaces, para generar un reporte pdf, y entre mas where tenia la consulta, era mucho mas rapido, incluso desde el manejador, o en una consulta directa de sql, en el caso de sql server o de access, entre mas filtros y mas si estos tienen indices.

[seyko]

Iniciado por nohemibaac

Corriendo una consulta, en un caso de oracle, tengo una tabla con 254,512 registros, tenia q hacer inner join con esa tabla a otras 4 más en 2 diferentes tablespaces, para generar un reporte pdf, y entre mas where tenia la consulta, era mucho mas rapido, incluso desde el manejador, o en una consulta directa de sql, en el caso de sql server o de access, entre mas filtros y mas si estos tienen indices.

Creo que estás equivocada.
Lo que te pasa en el caso de Oracle, es que el planificador saca un buen rendimiento de tus condiciones, pero eso no significa que a más condiciones mejor rendimiento, depende de las condiciones, de los indices, etc.

Tambien debes tener en cuenta que el rendimiento no se puede medir en "tiempo", porque depende de la carga de la BD, S.O., etc....
Si la select con más condiciones, reduce significativamente el número de resultados, logicamente la consulta es mucho más rápida, pero es porque tienes menos "datos" que entregar al informe.

Por tanto, esto para mi no es una prueba valida.

Un saludo

[Beakdan]

Tampoco para mí es una prueba válida. Es decir, ¿cómo lo cuantificas? ¿Cual es el costo por registro?

Supon que tienes un índice definido por dos campos A y B. Con una consulta como:

Código:

SELECT  A, B, ..., N
FROM    Table
WHERE   A = ? AND B = ?

El índice localizará de inmediato la página donde se localizan los datos. La demora dependerá unicamente del tiempo requerido para obtener la página.

Ahora la misma consulta con la condición:

Código:

WHERE   A = ? AND B = ? AND C = ?

Puede llegar a usar el mismo índice, pero debe discriminar los datos de la página para devolverte sólo lo que requieres. Obviamente el proceso de discriminación tiene un costo adicional que no pesaba sobre la primera consulta. Sin embargo, la cantidad de registros devueltos suele ser menor y por lo tanto da la impresión de que ha sido más rápida la consulta.

[quimfv]

No se como se pueden hacer ciertas afirmaciones despues de la clase magistral dada por matanga
Apoyado por Beakdan y seyko.

Que una vez una consulta me fue mas rapida en tres motores no prueba absolutamente nada. Bueno no se si a Access se le puede llamar motor...

Quim

[mafima]

OK, muchas gracias a todos, he entendido lo que me dicen y además he hecho tambien pruebas...

hasta luego

[alejandrooo1]

Tambien estoy deacuerdo con lo que ha dicho matanga.

La velocidad de la consulta queda expresada en la concecuencia que tiene al procesador. Entre menos procesador tiene en uso, significa que debio realizar menos calculos. Muchas veces creemos que por que aparece mas rapido en nuestra pantalla es mas rapida, lo unico que pasa es que como nuestro cpu no tiene que procesar y preparar un informe de muchos datos resultantes no demora tanto.

Matanga excelente respuesta.

[gnzsoloyo]

Lo siento, pero los temas resucitados se cierran, especialmente aquellos que llevan muuuucho tiempo muertos y que no aporte novedades al análisis.

Este tenía ya cinco años...