8 respuestas en este tema

[look]

Hola amigos, tengo la siguiente consulta en sql:

delphi

select NOMBRE, DIR, TEL
 from INFCLI01 
 where CLV_DOC = :CLV_DOC AND TIP_DOC = :TIP_DOC

como pueden ver recibe dos parametros "clv_doc,tip_doc", en esta tabla "infcli01" tengo creado un indice  para estos dos campos de esta manera "TIP_DOC,CLV_DOC" , mi duca es, ¿importa el orden de los campos?, ya que en la consulta esta "clv_doc,tip_doc" y en el indice "tip_doc,clv_doc", ¿tendria que cambiar mi consulta?, ¿afecta realmente este orden?.

Saludos!

[santiago14]

Yo creo que no varía.

Santiago.

[Wilson]

¿tendria que cambiar mi consulta?, ¿afecta realmente este orden?.

Para efectos del resultado no afecta en nada, para rendimiento podría ir más rápido si creas  índices individuales con cada campo de los que mencionas  (los involucrados en WHERE).

Saludos.

[look]

¿tendria que cambiar mi consulta?, ¿afecta realmente este orden?.

Para efectos del resultado no afecta en nada, para rendimiento podría ir más rápido si creas  índices individuales con cada campo de los que mencionas  (los involucrados en WHERE).

Saludos.

tengo una duda amigo, si creo indiviualmente los indicices como mencias creo que se afectaria la performacia, ya que como dices los involucrados en la sentencia where son estos dos campos , es por eso que el indice esta creado en base a ellos, si los creo de forma individual creo que afectara, no me considero un experto pero creo que asi va, si no me corrigen

[Wilson]

Crea los índices individuales y miras los tiempos de respuesta con Flamin Robin. Los índices compuestos en ciertas circunstancias no son tan eficientes.
Si va mal, pues los eliminas y listo (los recién creados).
En cualquiera de los casos deberías cambiar en tu consulta  el orden de los campos en el WHERE, filtrando primero el tipo de documento y luego el documento, sería un poco más rápida.

Saludos.

[santiago14]

Para que se entienda mejor.
Si NO creas los índices, el rendimiento sí se vería afectado.
Si creas un índice (con los dos campos), no importa demasiado si uno va antes que el otro.

No estoy seguro si el rendimiento mejora o no creando índices particulares (para esta consulta puntual claro)

Santiago.

[look]

No estoy seguro si el rendimiento mejora o no creando índices particulares (para esta consulta puntual claro)

Claro que si afecta amigo.

cheka esto, aunque no es de firebird explica cosas interesantes y aplicables:
http://msdn.microsof...y/jj835095.aspx

[santiago14]

Muy interesante... entonces tienen razón, el orden sí altera el producto.
Para los índices combinados hay que respetar el orden en el Where, para que sean usados.

Con esto, ponemos índices particulares y podría funcionar mejor.

Gracias.

[Sergio]

Todo esto tiene poco sentido: El optimizador de cada motor de datos es el encargado de usar los indices, alterar el orden de los where, etc. para que vaya lo mejor posible, así que diferentes versiones de firebird darán resultados distintos.

Lo que tendrías que mirar es si el "plan" que genera firebrid antes de lanzar la consulta cambia o no al modificar la consulta o añadir nuevos indices. Yo uso FlameRobin para estas cosas. Ah! Y si vas a comparar tiempos, recuerda para el servicio de FB entree cada prueba, la cache es potente y hace que una segunda prueba vaya más rápido que la segunda.

Personalmente -y sin base alguna- no creo que el orden en el where afecte lo más mínimo, el optimizador no es tan simple, pero si que debe afectar y mucho el que el indice compuesto lo hagas de una forma u otra. Al crear un indice compuesto "obligas" a aplicar primero el filtro en el primer campo, y luego en el segundo, y realmente interesa aplicar primero el que más discrimine datos (el que deje menos records tras aplicarlo) pero si tienes indices sueltos, el optimizador puede elegir.

Nosotros en la empresa usamos siempre indices sueltos, excepto si queremos que una combinacion de campos sea única, en cuyo caso si que interesa declarar un unique key, claro.