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:
y
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.
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.