cómo optimizar la base de datos mysql eficientemente

[inforob]

tengo una duda técnica,,,,

es recomendable, obligatorio, o contraproducente, el recoger los datos de una base de datos mysql, y guardarlos en variables de sesión para no tener que acceder al servidor ???

y si es asi? como se guardarían las variables de sesión para evitar conflictos,,,

[gnzsoloyo]

Depende....

¿Dispones de 250 Tb de RAM?



Lo siento, pero la pregunta se cae de cajón: Si eso fuese "eficiente", nadie programaría nada más que lecturas elementales a la base y resolvería todo en las aplicaciones... ¿No te parece?

No. no resulta eficiente desperdiciar recursos de memoria almacenando datos, el 99,999999% de los cuales no necesitas en ningún momento, para una sesión dada, de un usuario dado.
Eso, además de centenares de consideraciones que no te mencionaré ahora (las desventajas son demasiadas para listarlas).

[inforob]

Iniciado por gnzsoloyo

Depende....

¿Dispones de 250 Tb de RAM?



Lo siento, pero la pregunta se cae de cajón: Si eso fuese "eficiente", nadie programaría nada más que lecturas elementales a la base y resolvería todo en las aplicaciones... ¿No te parece?

No. no resulta eficiente desperdiciar recursos de memoria almacenando datos, el 99,999999% de los cuales no necesitas en ningún momento, para una sesión dada, de un usuario dado.
Eso, además de centenares de consideraciones que no te mencionaré ahora (las desventajas son demasiadas para listarlas).

de acuerdo pero entonces, conoces algún método para reducir el numero de peticiones al servidor de base de datos?

[gnzsoloyo]

Depende del sistema, del diseño de la base, de las optimizaciones de las consultas...
En definitiva, no es un modelo único. Sin plantear problemas concretos, no se puede dar una respuesta válida.

En principio, si hay exceso de peticiones a la base, lo que puede haber es una exagerada atomización de las consultas, y muy probablemente falta de optimización necesaria.
Ten en cuenta que lo que para tí pueden ser "demasiadas consultas", pueden ser en realidad "la menor cantidad de consultas posibles", si se las analiza profundamente.

Pero como dije, sin ver el sistema, estamos hablando vaguedades.

[inforob]

Iniciado por gnzsoloyo

Depende del sistema, del diseño de la base, de las optimizaciones de las consultas...
En definitiva, no es un modelo único. Sin plantear problemas concretos, no se puede dar una respuesta válida.

En principio, si hay exceso de peticiones a la base, lo que puede haber es una exagerada atomización de las consultas, y muy probablemente falta de optimización necesaria.
Pero como dije, sin ver el sistema, estamos hablando vaguedades.

digamos que el ejemplo que te comento, es recuperar 100-1000 registros de una base de datos (COMO MUCHO),,,,

los registros los almaceno en arrays, y pagino los resultados a través de estos arrays para no tener que hacer peticiones al servidor,,,

pero desconozco alguna otra forma más óptima

[gnzsoloyo]

Es un modo de hacerlo.
Pero el tema de la paginación o la cantidad de registros que almacenes en los arrays, no son tema de BBDD, sino de programación. A nosotros lo que nos interesa es cuán performántica es la consulta, no lo que haces con ella.
Si la consulta tarda 0,17 segundos en ejecutarse en servidor (muy probable dada la cantidad de registros), entonces tienes más tiempo de transacciones de red que de consulta y por tanto optimizar eso es irrelevante.
Pero si la consulta tarda 1, 2, 15, o 45 segundos en ejecutarse en el server, entonces tienes un problema de optimización de la consulta. Y eso es otro problema diferente, sobre el que sí podemos hablar.
Además de eso, para ver si es necesario o no lo que propones hay que ver otros detalles, por ejemplo:
- Si la tabla consultada es de elevado nivel de INSERT/UPDATE/DELETE, cargar en memoria es una mala idea, porque el usuario puede estar viendo datos irreales (lo que leyó, no lo que hay).
- Si las consultas traen más columnas de las necesarias, porque luego de seleccionar un registro pide detalles que no muestras al inicio, tu sistema es ineficiente y está transmitiendo enormes cantidades de "datos basura" (información no necesaria para la etapa del proceso), que bien puedes pedir después de modo más eficiente.
- Como todas las gestiones son asincrónicas, al no refrescar los datos, entonces ciertas cosas a realizar después pueden no poder hacerse.
- Bloquear las tablas para prevenir cambios, en tu contexto, generará bloqueos innecesarios y posibles casos de deadlocks.

En definitiva, yo no lo considero muy aconsejable, a menos que leyeses datos totalmente inmodificables.

[inforob]

Iniciado por gnzsoloyo

Es un modo de hacerlo.
Pero el tema de la paginación o la cantidad de registros que almacenes en los arrays, no son tema de BBDD, sino de programación. A nosotros lo que nos interesa es cuán performántica es la consulta, no lo que haces con ella.
Si la consulta tarda 0,17 segundos en ejecutarse en servidor (muy probable dada la cantidad de registros), entonces tienes más tiempo de transacciones de red que de consulta y por tanto optimizar eso es irrelevante.
Pero si la consulta tarda 1, 2, 15, o 45 segundos en ejecutarse en el server, entonces tienes un problema de optimización de la consulta. Y eso es otro problema diferente, sobre el que sí podemos hablar.
Además de eso, para ver si es necesario o no lo que propones hay que ver otros detalles, por ejemplo:
- Si la tabla consultada es de elevado nivel de INSERT/UPDATE/DELETE, cargar en memoria es una mala idea, porque el usuario puede estar viendo datos irreales (lo que leyó, no lo que hay).
- Si las consultas traen más columnas de las necesarias, porque luego de seleccionar un registro pide detalles que no muestras al inicio, tu sistema es ineficiente y está transmitiendo enormes cantidades de "datos basura" (información no necesaria para la etapa del proceso), que bien puedes pedir después de modo más eficiente.
- Como todas las gestiones son asincrónicas, al no refrescar los datos, entonces ciertas cosas a realizar después pueden no poder hacerse.
- Bloquear las tablas para prevenir cambios, en tu contexto, generará bloqueos innecesarios y posibles casos de deadlocks.

En definitiva, yo no lo considero muy aconsejable, a menos que leyeses datos totalmente inmodificables.

y como puedo medir los tiempos de respuesta del servidor??? utilizo un motor mysql y el gestor online phpmyadmin,,, pero desde un script no se cómo puedo ver el rendimiento de mis consultas ,,,

[gnzsoloyo]

Los scripts no son tema de este foro (Normas del Foro de Bases de Datos).
Eso lo tienes que preguntar en el Foro de PHP (en tu caso).
En cuanto a las consultas, el mismo phpMyadmin te muestra el tiempo de ejecución devuelto por MySQL cuando las ejecutas.

[inforob]

Iniciado por gnzsoloyo

Los scripts no son tema de este foro (Normas del Foro de Bases de Datos).
Eso lo tienes que preguntar en el Foro de PHP (en tu caso).
En cuanto a las consultas, el mismo phpMyadmin te muestra el tiempo de ejecución devuelto por MySQL cuando las ejecutas.

ok, gracias por la info