groupwisemaxが機能することは保証されていません。実際、MariaDBはそれを壊しましたが、それを取り戻すための設定を提供しました。これが私が言及していることです：
SELECT *
FROM
( SELECT ... ORDER BY ... )
GROUP BY ...
内部クエリの各グループの最初（または最後）が必要な場所。問題は、SQLがその意図を自由に最適化できることです。
ドキュメント内のグループごとの最大コードは非常に非効率的です。
クエリを高速化するために、おそらく少し役立つのは、Rulesを分離することです。 またはPlaces WHERE句の一部であり、対応するテーブルのPRIMARYKEYのみを返すサブクエリにします。次に、それをすべてのテーブルと一緒にJOINに入れます（同じテーブルに戻るJOINを含む）。そのサブクエリの「カバーインデックス」がすでにあるので、「インデックスの使用」（EXPLAINで使用される専門用語）にすることができます。
innodb_buffer_pool_sizeは使用可能なRAMの約70％に設定されていますか？
BIGINTは8バイトを取ります。あなたはおそらくMEDIUMINTUNSIGNED（0..16M）と一緒に暮らすことができます。より小さく->よりキャッシュ可能->より少ないI/O->より高速。
lat/lngのDOUBLEのペアは16バイトを使用します。 FLOATペアは8バイトを使用し、6フィート/2mの解像度を持ちます。または、緯度の場合はDECIMAL（6,4）、経度の場合は（7,4）で、7バイトおよび52フィート/16mの解像度です。特に距離に「円」ではなく「正方形」を使用しているため、「店舗」には十分です。
「最も近いものを見つける...」のコードを最適化するのは困難です。これが私が思いついた最高のものです： http://mysql.rjweb.org/doc .php / latlng