MySQL: ¿Cuántas consultas por página son demasiadas?

Question

Soy nuevo en MySQL y algo que se está volviendo obvio para mí es que se siente considerablemente más fácil crear varias consultas de bases de datos por página en lugar de algunas de ellas ... pero realmente no tengo una idea para cuántas consultas podrían ser demasiadas, o en qué punto debería invertir más tiempo valioso para combinar consultas, dedicar tiempo a encontrar combinaciones inteligentes, etc.

Me pregunto si hay algún tipo de "puntos de referencia mentales" personas experimentadas aquí usan con respecto al número de consultas por página, y si es así, ¿cuántas pueden ser demasiadas?

Entiendo que la respuesta correcta en cualquier contexto está relacionada con lo que se necesita para satisfacer los requisitos funcionales de una aplicación. Sin embargo, en proyectos donde los requisitos del cliente pueden ser flexibles o no están configurados correctamente, o en proyectos donde usted como desarrollador tiene control total (por ejemplo, sitios que desarrolla por sí mismo), puede negociar entre funcionalidad y rendimiento ... básicamente, simplemente cortar características triviales si los requisitos de codificación afectan el rendimiento y no puede optimizarlo aún más.

Agradecería cualquier opinión sobre esto.

Gracias

Answer 1

Depende de la frecuencia con la que se usa la página, la latencia entre el servidor de la aplicación y el servidor de la base de datos, y muchos otros factores.

Para una página que solo muestra datos, mi intuición es que 100 es demasiado. Sin embargo, hay algunos casos en que eso puede ser aceptable.

En la práctica, solo debe optimizar cuando sea necesario, lo que significa que optimiza las páginas que las personas más utilizan, e ignora las menores.

En particular, las páginas no están disponibles para el público y los (pocos) usuarios autorizados apenas las usan, no hay ningún incentivo para agilizarlas.

Si hay un verdadero problema de rendimiento que se cree que proviene de tener demasiadas consultas, permitirá el registro de consultas en general (que puede hacer que el rendimiento es peor, me temo) y analizar los más comunes consultas con miras a eliminándolos.

Es posible que haya algunas "frutas colgantes": consultas sencillas sobre datos raramente cambiantes que se solicitan en las páginas más populares, que puede eliminar fácilmente (por ejemplo, haga que su servidor de aplicaciones obtenga los datos en cron trabajo en un archivo local y leerlo desde allí). O incluso "frutas colgantes inferiores" como consultas que son completamente innecesarias.

La dificultad de intentar combinar varias consultas es que tiende a ir en contra de la reutilización de código y la mantenibilidad del código, por lo que solo debe hacerlo si es ABSOLUTAMENTE necesario; no parece que tengas datos suficientes para tomar esa determinación.

Answer 2

No hay un número fijo, "página" es bastante arbitraria - uno podría estar haciendo una tarea de base de datos, mientras que otro podría tener 2 docenas de widgets de cada uno con su propia tarea.

Sin embargo, una buena regla general: en el momento en que coloca un SELECT dentro de un bucle que procesa filas de otro SELECT, finalice. Puede parecer lo suficientemente rápido desde el principio, pero los datos tienden a crecer y esos bucles anidados crecerán exponencialmente con él, por lo que se espera que se convierta en un cuello de botella en algún momento. Incluso si la consulta individual termina siendo significativamente más lenta, será mejor a largo plazo (y siempre hay procs almacenados, caché de consultas, etc.).