Posted 19 August 2014 - 04:48 AM
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.