El 21 de junio de 2012 21:34, Alvaro Herrera <alvhe...@alvh.no-ip.org>escribió:
>
> Excerpts from Sergio Valdes Hurtado's message of jue jun 21 17:33:29 -0400
> 2012:
> > El 21 de junio de 2012 17:06, Alejandro Carrillo <faster...@yahoo.es
> >escribió:
> >
> > > 1) Crea un indice por cada campo que vayas a filtrar con frecuencia:
> rbd,reg_cod,ano_pago,
> > > ind_reli,rut_sost ; es decir no crees indices compuestos ya que estos
> > > exigen que la consulta se haga por todos los campos.
> > >
> > En realidad las tres consultas son ídenticas, sólo cambian en el where ,
> > ya que una es rbd in (..), la otra es rut_sost in(..) y la última reg_cod
> > in (..). La primera trae pocos datos ya que normalmente se pregunta por
> uno
> > o dos rbd, la segunta trae mas datos, ya que un rut_sost puede tener
> varios
> > rbd y la última es la que mas datos trae, ya que un reg_cod tiene muchos
> > rut_sost.
> > ¿Debo crear índices distintos para cada una de las consultas?
>
> No. Mientras menos índices, mejor, porque los INSERT y UPDATE son más
> lentos mientras más índices hay.
>
> > ¿Deben ser índividuales o compuestos?
>
> Eso depende. Lo que dice Alejandro, más arriba, no es cierto: si tienes
> índices en los campos (a,b,c) pueden usarse para atender consultas con
> WHERE a, b. Así que la decisión de si usar individuales o compuestos no
> depende de otros factores.
>
> Yo pienso que te puede servir un índice así
> create index fff on tabla (rbd) where ind_reli in ('S', 'N')
> sobre todo si hay muchos otros casos en ind_reli.
>
> --
> Álvaro Herrera <alvhe...@alvh.no-ip.org>
>
bien, probaré creando tres indices, uno que contenga rbd, ano_pago,
mes_pago e ind_reli (where ind_reli ..)
otro con rut_sost, ano_pago, mes_pago e ind_reli (where ind_reli ..) y el
ultimo con reg_cod, ano_pago, mes_pago e ind_reli (where ind_reli ..)
Veré que pasa y les cuento
--
Sergio Valdés H.
