❓

Consultas MySQL consumen más dentro de procedimientos que como instrucciones separadas

⋮

Estoy por desarrollar un sistema en VB.NET y MySQL y necesito conocer sus opiniones. Para optimizar recursos, los procedimientos almacenados simples (Select, update, insert y delete, solo con algún IF) consumen más recursos en el servidor que si envío todas las instrucciones separadas por ;?

Consulto ya que en muchos casos, debo hacer un select y usar ese valor en un insert o delete, pero no deseo disparar el consumo en el servidor por si necesito utilizarlo con algún servicio con recursos medidos.

¿Se entiende la consulta? Leo todas sus opiniones

Comparte

Inled ayer 22:19

⋮

Técnicamente, diría que consume menos recursos utilizar procedimientos almacenados, por que le ahorras al servidor toda la parte de parseo (es decir, convertir las sentencias SQL en instrucciones con las que puede trabajar el sistema), aunque no puedo asegurar que sea así.

A efectos prácticos, te diría que elijas la opción más cómoda para programar. Las bases de datos son sistemas con una eficiencia increíble, y probablemente ni siquiera llegues a notar la diferencia entre estos dos modos. En mi experiencia, trabajar con procedimientos almacenados es bastante más incomodo que escribir directamente las sentencias sql (piensa en tener que hacer algún cambio a alguno de los procedimientos, por ejemplo

Lobo Anonimo ayer 22:21

⋮

Soy Database Engineer y Senior Web Developer.

Suelen decir que los Stored Procedures son mejor para el rendimiento del servidor, porque son "precompiled". En vez de mandar un query largo, el servidor ya tiene el query y tu solo mandas el nombre del query que quieres lanzar.

Trabajo en una empresa de datos donde movemos TB's de datos todos los dias y en mi experiencia se pueda ganar muchisimo más rendimiento optimizando bien tus tablas, queries e indexes.

Nosotros por ejemplo en vez de hacer un query super intensivo en el servidor MySQL que pueda tardar 2 minutos en cargar, preferimos sacar los datos de MySQL con un query simple para luego procesarlos lentamente en otro servidor web.

En nuestro caso tambien hay tantisimos cambios en los queries, que no nos resulta util usar stored procedures.

Puede ser util para tu aplicacion, pero cada aplicacion es diferente.

Amenhotep ayer 23:40

⋮

Hay dos tipos de consumo: de CPU o de ancho de banda. No creo que tener el procedimiento almacenado ahorre mucho ancho de banda, ya que lo unico que suprimes es el envio de la orden SQL.

Si quieres ahorrar ancho de banda procura hacer consultas solo de los campos necesarios y bien delimitadas por WHERE. Es decir no hagas un SELECT * FROM y luego en VB.NET filtres los registros uno a uno, sino que debes filtrarlos usando la propia consulta y seleccionar bien los campos que vas a usar.

Respecto del consumo de CPU, para la mayor rapidez y menor uso de CPU hay que establecer índices en todos los campos que vayan a usarse en relaciones o cláusulas WHERE.

✖

rbetancor hoy 01:16

-1

⋮

Hay dos tipos de consumo: de CPU o de ancho de banda. No creo que tener el procedimiento almacenado ahorre mucho ancho de banda, ya que lo unico que suprimes es el envio de la orden SQL.

He visto ORMs enviar al servidor consultas SQL de 4 páginas, así que no descartes tanto eso de que "no ahorras mucho ancho de banda".

✖

Amenhotep hoy 10:04

⋮

Se me había olvidado: Si quieres optimizar SQL nunca jamás hay que usar un ORM.

No existe ningún ORM orientado a optimizar SQL sino a ser bonitos y chachis de cara al programador.

Hay que crear consultas propias y si acaso agruparlas en procedimientos de objetos del lenguaje de backend utilizado basándose en la lógica de flujo de la aplicación.

rbetancor hoy 01:21

⋮

Como en la mayoría de las áreas de IT … "depende" … y aquí pues depende mucho de lo bueno que seas diseñando la base de datos, las tablas (hay gente que se obsesiona con el 5NF y hay tarugos que siniquiera relacionan bien 2 tablas), indices adecuados, consultas bien estructuradas, configuración del RDBMS, etc.

Por lo general, suelo usar procedimientos almacenados, como funciones de ejecución de triggers, ya que así me ahorro la lógica en la aplicación, para eso está el RDBMS. Incluso para cálculo de estadisticas, con un buen diseño de las tablas, te puedes ahorrar mucho trabajo desde el lado de la aplicación, precalculando ciertos valores al utilizar procedimientos almacenados.

En resumen, que depende más del diseño de la aplicación y la base de datos. No se puede dar una respuesta genérica.

✖

Amenhotep hoy 10:09

⋮

En efecto: Los triggers y procedimientos almacenados ahorran mucha lógica en el lenguaje de backend, ahorran transacciones y además evitan errores en el proceso de datos.