Rendimiento UDF en MySQL

Question

Noto una degradación exponencial del rendimiento en los tiempos de ejecución de consultas de MySQL cuando las consultas incluyen llamadas a UDF en las cláusulas SELECT o WHERE. Los UDF en cuestión consultan tablas locales para devolver valores escalares, por lo que no solo realizan expresiones aritméticas, sino que sirven como subconsultas correlacionadas. He solucionado el problema de rendimiento simplemente quitando los UDF y reescribiendo con subconsultas correlacionadas, combinaciones más complejas, etc.

Supongo que si solo tuviera experiencia con MySQL, simplemente lo aceptaría como una realidad, ajustaría mi uso de UDF y seguiría adelante. Pero antes de trabajar con MySQL trabajé por más de 5 años en SQL Server. Creé un sistema de facturación que procesaba conjuntos de datos mucho más grandes y confiaba muy en gran medida en las funciones definidas por el usuario tanto escalares como de valor de tabla. Esos UDF también realizaron consultas (es decir, no solo operaciones aritméticas). No experimenté este tipo de penalización de rendimiento al usar funciones definidas por el usuario en SQL Server.

Lo que me pregunto es si hay alguien aquí que conozca SQL Server vs. MySQL internos lo suficientemente bien como para confirmar o explicar mi teoría actual sobre la causa de esta diferencia de rendimiento en UDF en los dos sistemas. Mi teoría es que el optimizador de SQL Server evalúa los UDF de manera diferente que MySQL. ¿Quizás es porque los motores de la tabla están desacoplados en MySQL? ¿O tal vez el uso de UDF en SQL Server es más frecuente y el optimizador del motor MySQL simplemente no ha evolucionado hasta ahora? Lo que estoy pensando es que tal vez el optimizador de SQL Server trata los UDF incluidos como parte de la consulta circundante (cuando sea posible) y luego lo optimiza junto con el resto de la consulta. Tal vez estoy fuera de lugar aquí, pero nunca vi este tipo de éxito en el rendimiento por usar UDF en SQL Server.

Se apreciará cualquier luz que otros puedan arrojar sobre este tema.

Answer 1

Las UDF tienen limitaciones y problemas conocidos. Consulte: ¿Las UDF son perjudiciales para el rendimiento del servidor SQL?

Hay muchos artículos sobre este tema. Esperemos que este sea un acceso para no suscriptores: Cuidado con las operaciones fila por fila en UDF Ropa

Answer 2

Sé que esta es una pregunta antigua, pero aparece primero en la búsqueda de Google de "MySQL UDF performance". y aún no tiene una respuesta adecuada: un enlace en la respuesta aceptada está roto, el otro no parece hablar sobre los detalles de las UDF de MySQL.

Primero, asegurémonos de que estamos hablando de los UDF MySQL reales. En MySQL, hay una distinción entre una " función almacenada " y un UDF. Una función almacenada se ejecuta utilizando el intérprete interno de función / procedimiento almacenado. Un UDF está escrito en C ++ y se compila en una biblioteca compartida que el servidor MySQL carga en la memoria y, cuando se llama, se ejecuta como código de máquina en la CPU. Por lo tanto, el rendimiento de UDF suele ser mucho mejor que el de las funciones almacenadas.

Entonces, antes que nada, asegúrese de estar hablando del UDF real, y esta no es una función almacenada.

Segundo, el rendimiento de MySQL UDF depende de la naturaleza del algoritmo que está ejecutando y de la calidad de su implementación. Por ejemplo, si su UDF está probando todos los tripletes posibles de caracteres de una cadena de 1000 bytes de longitud, examinará mil millones de combinaciones y tomará alrededor de varios segundos por fila. Entonces, si eliminar los UDF hace que su código se ejecute significativamente más rápido, el siguiente paso es depurar el UDF para asegurarse de que esté escrito de manera óptima, o tal vez la pregunta que el UDF está tratando de responder simplemente no se puede responder rápidamente.

Dicho esto, un UDF bien escrito que está respondiendo una pregunta relativamente simple generalmente es muy rápido en comparación con la E / S necesaria para alimentar los datos para analizar.