Hola
Cita:
Empezado por mamcx
Ese no es el mismo query del principio -pero pasa igual?-, y no estan los tiempos. Sin embargo si es un producto cartesiano no importa que ALMAC sea pequeña, igual deberia tener los indices. Segun el plan, hay una lectural natural (ie: lee cada registro de la tabla). Probaste poniendo indices?
Y por favor, usa el mismo dato para hacer evaluaciones y medidas, si cambias los querys cada vez pues como se puede determinar exactamente la causa?
|
Desde el principio estoy con dos consultas: la del "merge" (origen del hilo) y esta del "exists":
Código SQL
[-]Select artic.artic, almac.cod as almac from artic, almac where artic.activo = 'S' and artic.filtro = 'MP' and not exists ( Select artal.artic from artal where artal.artic = artic.artic and artal.almac = almac.cod)
Todas las pruebas que os voy poniendo están hechas con la consulta anterior (pensando en un "insert into" en lugar de un "merge"). La tabla "almac" es una auxiliar de código/descripción con clave primaria por código, si no usa ese índice es porque no hay condiciones para el uso y porque necesita todos los registros (en eso consiste la consulta: los artículos seleccionados en todos los almacenes).
Cita:
Empezado por mamcx
Lo ultimo se me ocurre, es que el disco este fragmentado, o que las estadisticas de los indices esten desincronizadas. El que vuele con SSD muestra en parte eso (los SSD no se fragmentan, y tienen IO superveloz). Es claro, desde mi punto de vista, que FB esta leyendo datos del disco y no desde los indices (en memoria). La 2da vez es rapido porque tiene los planes, indices, etc precalculados y las estadisticas corregidas... |
El disco lo tengo desfragmentado: manías de uno que una vez al mes pasa ese proceso (más al andar con archivos de grandes volúmenes de aquí para allí. Los índices están bien, como ya dije no he dado de alta ningún registro y otra manía que tengo es al recibir una BD de un cliente pasarle una serie de procesos de mantenimiento. Así que sinceramente creo que es rápido por lo primero que has dicho (tienen IO superveloz), unos 450 MB/s en lectura secuencial que es lo que toca. ¿Al hacer un backup/restore también tiene el plan de la consulta calculado?
Por cierto no sé a qué te refieres con los tiempos, la consulta la ejecuté con iSQL calculando sólo el plan (Set planonly on).
un saludo y gracias por el interés