Rendimiento en consulta sobre la LedgerTrans
He realizado muchas informes tanto en reporting services, crystal report y los estándar de AX, y estaba realizando una consulta en AX para los saldos a fecha.
En principio los había calculado sobre el campo AmountMST, pero el cliente me lo ha pedido sobre el campo AmountCur. Para optimizar hice una consulta directa sobre SQL server y luego cargaba los datos sobre una tabla temporal para que luego ellos pudieran exportarlo a Excel con la funcionalidad estándar.
Mi sorpresa ha sido mayúscula, porque incluso haciendo la misma consulta en SQL Server pero sobre diferentes campos la diferencia de rendimiento ha sido enorme.
Desde SQL Server aplicando los mismos filtros, es decir sobre la compañía he calculado el sumatorio en la ledgertrans del campo AmountMST y del campo AmountCur, y para el AmountCur ha tardado 31 segundos y para el AmountMST 7. Imaginaros si tengo que buscar el saldo para cada una de las cuentas por fecha lo que ha podido tardar.
Hasta ahora no me había percatado de esta diferencia tan grande en la búsqueda sobre la misma tabla, con el mismo filtro en el where, pero sumariando sobre diferentes campos, y a nivel de SQL ambos campos reales.
[AMOUNTMST] [numeric](28, 12) NOT NULL,
[AMOUNTCUR] [numeric](28, 12) NOT NULL,
Alguién sabe a que puede ser debido esta diferencia. Yo estoy investigando, en cuanto de con ello os lo comunicaré
Etiquetas: AmountCur, AmountMST, LedgerTrans, SQL, Server, X++
Respuestas a esta discusión
-
Permalink Responder para José Antonio Estevan el -
Hola,
He estado echando un vistazo rápido porque me llamado la atención el caso que comentas y la única explicación "lógica" es que el campo AmountMST está incluido en un índice del estándar.
Entrecomillo lo de "lógica" porque no se me ocurre un motivo por el que incluir un campo como este en una clave. Tampoco se me ocurre el por qué influye en el sumatorio el hecho de que forme parte de una clave. Cabe pensar que para sumar el dato hay que recorrer la tabla de cualquier manera, esté o no en el índice. Seguro que hay alguien en el foro que nos podrá ilustrar sobre esto.
Y si no lo hay podemos usar una lógica que suele funcionar: Si los desarrolladores del estándar han definido esa clave en una tabla tan delicada como esa, por algo será :D
-
Permalink Responder para Adolfo Castillo el -
Curiosamente aunque no lo especifiques en el where de la consulta lo aplica porque es el resultado de devolcuión.
Muchas veces usar un índice y llamarlo por menos campos de los que contiene el índice, penaliza el rendimiento, pero en este caso se ve que no.
Sólo habría de probarse a duplicar el índice ya existente y sustituir por el campo AmountCur y verificar que los tiempos son los mismos.
-
Permalink Responder para José Antonio Estevan el
-
esa tabla tambien es muy utilizada por AX en general, si el entorno en el que estas probando esta en producción o semi-producción (test), hay que tener en cuenta también al optimizador de sql server que puede dar prioridad a ese índice porque ha "aprendido" que le suele funcionar bien.
hay que ver lo lista que es a veces la bbdd y lo tontos que nos hace a la vez, son de esas cosas que te preguntan y nunca eres capaz de contestar con convicción xD
Bienvenido a
El Rincón Dynamics
Grupos
Vídeos
© 2012 Creado por Antonio Gilabert.
