Hola, Gracias por lo de las fechas, pero creo que sobre las fechas no hay indices en las tablas. Porque en realidad se realiza filtros por varios campos, no se si tiene alguna ventaja usar el dateadd si no tiene indices o si deberiamos crear los indices sobre muchos campos
Me seria util algun link que explique que hay que tomar en cuenta para decidir si poner o no un indice, porque imagino que no poner ningun indice esta mal y poner indice en todos los campos tambien esta mal En cuanto a los del SP que es el tema principal, el problema es lo que dijiste: Cuando se ejecuta el SP es mas lento que cuando se ejecuta la consulta directamente (exista o no un trace). Pero no entendi la diferencia entre compilar algo usando la alternativa menos mala o usando el criterio de la mejor alternativa Gracias, Diego _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jose Mariano Alvarez Sent: Sábado, 07 de Abril de 2007 20:02 To: Diego Jancic Subject: [dbms] Performance entre SP y Consulta directa Unos cuantos detalles. No me queda claro si el problema es cunado prendes el trace o cuando ejecutas el SP Si el problema es el segundo o sea cunado ejecutas el SP es mas lento, creo que el problema se debe a un fecomeno clasico de los SP ya que se compilan tomando el cuenta la alternativa menos mala y cuando usas T-SQL embebido se compilan siempre (eso es un costo adicional de CPU) usando el critero de la mejor alternativa. Algo mas importante y que quiza mejore drasticamente algunas de tus consultas si tienes los indices adecuados. Nunca escribas una condicion asi AND DATEDIFF(day, b.fecha_desde, getdate()) < 30 Esto NUNCA va a usar un indice mediante un SEEK y va a afectar al motor DEBES SIEMPRE escribirla de esta forma si quieres que use un indice b.fecha_desde < DATEADD(day, -30, getdate()) Saludos - -------------------------------- Atte. Ing. Jose Mariano Alvarez
