No se garantiza que el grupo máximo funcione. De hecho, MariaDB lo rompió, pero proporcionó una configuración para recuperarlo. Esto es a lo que me refiero:
SELECT *
FROM
( SELECT ... ORDER BY ... )
GROUP BY ...
donde desea el primero (o el último) en cada grupo de la consulta interna. El problema es que SQL es libre de optimizar esa intención.
El código máximo de grupo en los documentos es terriblemente ineficiente.
Para acelerar la consulta, una ayuda probable es aislar las Rules o Places parte de la cláusula WHERE y conviértala en una subconsulta que devuelva solo la CLAVE PRINCIPAL de la tabla correspondiente. Luego, póngalo en un JOIN con todas las tablas (incluido un JOIN de regreso a la misma tabla). Ya tiene un "índice de cobertura" para esa subconsulta, por lo que puede ser "Índice de uso" (en la jerga utilizada por EXPLAIN).
¿Innodb_buffer_pool_size está configurado en aproximadamente el 70 % de la RAM disponible?
BIGINT ocupa 8 bytes; probablemente podría vivir con MEDIUMINT UNSIGNED (0..16M). Más pequeño --> más almacenable en caché --> menos E/S --> más rápido.
El par de DOBLES para lat/lng ocupan 16 bytes. Un par FLOAT tomaría 8 bytes y tendría una resolución de 6 pies / 2 m. O DECIMAL(6,4) para latitud y (7,4) para longitud para 7 bytes y una resolución de 52 pies / 16 m. Suficientemente bueno para "tiendas", especialmente porque estás usando un 'cuadrado' en lugar de un 'círculo' para la distancia.
El código para "buscar el más cercano..." es difícil de optimizar. Aquí está lo mejor que se me ocurrió:http://mysql.rjweb.org/doc .php/latlng
