mysql - tablas - ¿Qué tan malo es tener consultas de bases de datos "extra"?

optimización de consultas bases datos

Question

Vengo del mundo del front-end en el desarrollo web donde intentamos realmente limitar el número de solicitudes HTTP emitidas (mediante la consolidación de archivos css, js, imágenes, etc.).

Con conexiones db (MySQL), obviamente no desea tener conexiones innecesarias, pero como regla general, ¿qué tan malo es tener múltiples consultas pequeñas? (ejecutan rápidamente)

Lo pregunto porque estoy moviendo mi aplicación a un entorno en clúster y donde antes estaba almacenando algunas cosas en la memoria del servidor (ya que estaba ejecutando en un único servidor), ahora estoy tratando de hacer que mi aplicación sea "sin estado" y en mi actual implementación que significa más llamadas db pequeñas. Esto me ayudará con el equilibrio de carga (evitando las sesiones adhesivas) y también mantendrá el uso de memoria del servidor.

No estamos hablando de un montón de consultas, tal vez de 6-8 llamadas a través de la red en lugar de 2-4, que van desde un puñado de registros a unos miles de registros. Cada uno de ellos se ejecuta rápidamente, menos de 30 ms (algunos mucho menos), pero no sé si hay alguna "latencia de conexión" que me preocupe.

Gracias por tu visión.

Answer 1

Respuesta corta: (1) asegúrese de permanecer en el mismo nivel de O grande, reutilice las conexiones, mida el rendimiento; (2) piense cuánto le importa la coherencia de los datos.

Respuesta larga:

Actuación

Estrictamente desde la perspectiva del rendimiento, y en términos generales, a menos que ya esté cerca de maximizar sus recursos de base de datos, como las conexiones máximas, es probable que esto no tenga un gran impacto. Pero hay ciertas cosas que debes tener en cuenta:

• ¿las consultas "6-8" que reemplazan las consultas "2-4" permanecen en el mismo tiempo de ejecución? por ejemplo, si la interacción de la base de datos actual está en O(1) , ¿cambiará a O(n) ? ¿O la O(n) actual va a cambiar a O(n^2) ? En caso afirmativo, debes pensar en lo que eso significa para tu aplicación
• la mayoría de los servidores de aplicaciones pueden reutilizar las conexiones de bases de datos existentes o tener grupos de conexiones de bases de datos persistentes; asegúrese de que su aplicación no establezca una nueva conexión para cada consulta; de lo contrario, esto lo hará aún más ineficiente
• en muchos casos comunes, principalmente en tablas más grandes con índices complejos y combinaciones, hacer pocas consultas por claves primarias puede ser más eficiente que unir esas tablas en una sola consulta; este sería el caso si, al hacer tales uniones, el servidor no solo tarda más en realizar la consulta compleja, sino que también bloquea otras consultas en las tablas afectadas

En términos generales, sobre el rendimiento, la regla de oro es: medir siempre.

Consistencia

Sin embargo, el rendimiento no es el único aspecto a considerar. También piense cuánto le importa la coherencia de los datos en su aplicación.

Por ejemplo, considere un caso simple: tablas A y B que tienen una relación de uno a uno y usted está buscando un solo registro usando una clave principal. Si se une a esas tablas y recupera el resultado con una sola consulta, obtendrá un registro de A y B , o bien no habrá registros de ninguno, que es lo que su aplicación también espera. Ahora considere si divide eso en 2 consultas (y no está usando transacciones con niveles de aislamiento preferidos): obtiene un registro de la tabla A , pero antes de poder tomar el registro correspondiente de la tabla B , es eliminado / actualizado por otro proceso Ahora su aplicación tiene un registro de A pero ninguno de B

La pregunta general aquí es: ¿te preocupa el cumplimiento de ACID de tus datos relacionales en lo que respecta a las consultas que estás rompiendo? Si la respuesta es sí, debe pensar cómo reaccionará la lógica de su aplicación en estos casos específicos.

Answer 2

6-8 consultas para una página web? Por lo general, esto está bien. Lo hago todo el tiempo.

¿Miles de filas regresaron? ¡Ahogo! ¿Qué va a hacer el cliente con tantos? ¿Puede el SQL hacer más procesamiento y luego devolver menos filas?

Con raras excepciones, solo 1 conexión por página web.

Cada consulta tiene muchos gastos generales. Por ejemplo, al INSERTing 100 filas en una tabla, 100 INSERT sola fila tomará aproximadamente 10 veces más tiempo que una sola fila de INSERT . Entonces, cuando sea práctico, use menos viajes redondos al servidor. Esto se vuelve muy importante si la red es una WAN. El otro lado del globo está a 250ms de distancia, solo por latencia. Un servidor en el mismo centro de datos probablemente esté tan cerca que la latencia se puede ignorar. En una WAN, use las Rutinas almacenadas para minimizar los viajes redondos.

Me gusta cronometrar cada consulta activamente en el código. Entonces, si percibo un problema de rendimiento, busco ver en qué consulta trabajar primero. O usa el SlowLog.