bbdd MySQL ciudades del mundo. Problema

[negro81]

Hola, mirad tengo una base de datos con las ciudades del mundo, la bbdd pesa unos 60MB, bien, la base de datos está implantada y sin problemas, el problema está en una aplicación que tengo que primero abre los países, cuando eliges un país, abre las regiones/provincias y cuando pulsas en una región viene el problema y es que tarda mucho en listar las ciudades, la aplicación recoge el id de la región y tiene que mostrar las ciudades, la consulta es simple pero siempre tarda la primera vez que se hace. Si después pulsas en otra provincia ya va rápido. ¿Es que MySQL crea algún tipo de caché? ¿Alguien sabe qué puede ser lo que pasa? Muchas gracias

[gnzsoloyo]

¿Es que MySQL crea algún tipo de caché? ¿Alguien sabe qué puede ser lo que pasa? Muchas gracias

Todos los DBMS usan alguan forma de caché de consultas. Es necesario por la complejidad de los procesos y la forma de segmentar los paquetes de datos.
Leer: 5.12. La caché de consultas de MySQL

[negro81]

Gracias por responder, he estado echando un vistazo y no me resuelve mi duda porque según pone ahí las consultas deben ser idénticas y en mi caso no es así, yo pulso en una provincia y tarda mucho, como 20 segundos, y luego pulso en cualquier otra provincia y ya siempre tarda 1 segundo. Cuando reinicio la aplicación igual, la primera vez que pulso tarda un rato y a partir de la segunda no tarda nada.

[gnzsoloyo]

Estás perdiendo el detalle: La igualdad de sentencias no es la única razón por la que una consulta puede ser más o menos rápida, o que una consulta puede ser cacheable. Hay otras múltiples razones.
- La ruta de los paquetes de datos por la web.
- La apertura/cierre de las conexiones impacta directamente en la performance la consulta. Si la primera consulta tiene también que abrir la conexión, será siempre más lenta.
- Los tipos de conexión usados.
- Los índices usados en la consulta.
- El nivel de selectividad de los datos buscados.
- La longitud de los registros y la cantidad de bloques de datos usados por el DBMS.

Para darte una idea mínima:

Código MySQL:

SELECT * FROM tabla;
 

y

Código MySQL:

SELECT * FROM tabla WHERE campo_no_Id>= unvalor;
 

donde campo_no_id es un campo común ienen el mismo costo de consulta en cuanto a uso de memoria, accesos a disco y comunicaciones.

Código MySQL:

SELECT * FROM tabla WHERE campo_no_Id>= unvalor;
 

donde campo_no_id es clave de índice, puede requerir x/64Kb veces menos de tiempo de búsqueda, siendo x el tamaño en bytes del índice.

Con esto quiero decir que si bien el caché de consultas afecta mucho, más aún afectan las optimizaciones de las consultas, y cuando tu mandas la segunda, a buscar las localidades de una zona de un país específico, es esperable que tarde menos que la consulta de países, porque la primera no está optimizada por PK y la segunda si...

Eso sin contar con los problemas de enlace y de hardware.

Recuerda, los DBMS no realizan las consultas siempre de la misma forma, y ejecutar dos veces la misma consulta puede incluso durar diferente, porque puede haberse realizado por métodos diferentes.
El plan de consulta de un DBM depende no sólo de la escritura de la consulta, sino de los resultados estadísticos que ese DBMS tenga almacenados y que usa para optimizar los métodos. Esa es una parte que mucha gente se olvida: Los DBMS tienen "memoria" de lo que hicieron y cómo lo hicieron. Se usa para decidir que es mejor para una consulta determinada.