Consultas SQL máximas por página

Question

Esta pregunta probablemente no tiene una respuesta definitiva, por lo que si se considera subjetiva y, digamos mala, no dude en cerrarla.

Básicamente estoy desarrollando una aplicación web bastante grande (PHP), y usa CakePHP. En este momento está en desarrollo y algunas cosas en la Base de datos son realmente complejas, por lo tanto, se deben realizar muchas consultas para mostrar las páginas (entre 7 y 25 consultas).

Dado que este será probablemente uno de gran escala, me gustaría saber cuál es el máximo, es decir, una especie de punto que indica que "Probablemente estás haciendo algo mal y debería optimizar ", cantidad de consultas SQL que se deben realizar por página. Tengo un sistema de caché muy simple configurado en este momento que reduce las consultas ejecutadas por un solo usuario a alrededor de 5 por 15 segundos.

¿Se realizan 25 consultas mucho? ¿Debo detener el desarrollo (tengo mucho tiempo) por un tiempo y refactorizar el código, eliminar consultas SQL que no se utilizan y dedicar tiempo para mejorar el rendimiento en esta parte?

Esto probablemente suena un poco confuso, por lo que continuó: ¿Hay un de facto máximo para el número de consultas corrió por página que no clavar un servidor (es decir, un entorno de alojamiento compartido)?

Gracias.

Answer 1

El número total de visitas a su base de datos también es proporcional al número de visitas a la página. Por lo tanto, si las consultas de páginas vistas * por página son más que la capacidad de su base de datos, entonces tiene un problema. Obviamente, el tráfico varía mucho de un sitio a otro, al igual que la capacidad de la base de datos, por lo que realmente no puede haber un número al que apuntar.

Answer 2

Como se menciona recursivamente, no hay un número mágico. Demasiadas variables Tales como las especificaciones de su servidor de base de datos. Claramente, cuanto mejor sea el servidor, más consultas podrá ejecutar.

Answer 3

Un método de optimización posiblemente más fácil y casi tan eficaz sería realizar consultas por lotes donde sea posible. De esta forma, realizará menos viajes de ida y vuelta al servidor de la base de datos, manteniendo intacta su lógica existente (en su mayoría).

Answer 4

Lo más importante no es el número, pero los gastos de la consulta ...

corriendo 100 SELECT name FROM foo WHERE id = 1 LIMIT 1 será mucho mejor que correr 1 de los siguientes:

SELECT * 
    FROM foo AS a 
    JOIN bar AS b 
    JOIN car AS c 
    WHERE a.col LIKE '%f%' OR b.col LIKE '%b%' OR c.col LIKE '%b%' 

Así no se preocupe por el número a menos que sea absurdo (Más de 100 es alto. Varios miles son absurdos) ... No olvide que puede habilitar el Query Cache de MySQL ... Entonces, incluso si está respondiendo muchas consultas por segundo, siempre que no haya un montón de actualizaciones, la mayoría de ellas serán resultados de la memoria caché directamente.