最初のコメント...
私はここや他のフォーラムで数十（数百万ではない）の実装を見てきました。あなたのものはほとんどよりも優れています。
あるデータソース（私がたまたまダウンロードしたもの）によると、世界には約320万の都市があります。
パフォーマンスのために、すべての3M行をチェックすることを避ける必要があります。あなたは成長するバウンディングボックスで良いスタートを切りました。持っている必要があることに注意してください
INDEX(lat, lon),
INDEX(lon, lat)
オプティマイザーは、それらと最初のクエリ（COUNT(*)を使用）のどちらかを選択します ）それを「カバー」として表示します。それは地球の周りの縞またはくさびになります。 3M行を超える明確な改善。最悪の緯度（+34度）には96Kの都市があります。 （1度=69マイル/111 km。）10分の1度の場合、34.4が最悪で、1万の都市があります。
（はい、私はこの種のデータパズルを楽しんでいます。）
そして、私はあなたがデートラインとポールを扱っているのを見ます。特別な場合としてそれらを持っていることであなたが改善することはできないと思います。
（私は数式と定数を一瞥しただけです。）
ジオハッシュとZ階数のインデックス作成が役立ちます。ただし、ターゲットの周囲に最大4つの領域をチェックする必要があるという問題があります。整数199999と200000は、それぞれの最初の桁が異なっていても、実際には互いに近いことに気付いていないようです。
「ユーザーは郵便番号または都市名を渡します」-これは、2つの単純なテーブルの1つへのポイントクエリです。 （重複がある可能性があることを除いて、「sanjose」と「sanantonio」はそれぞれ320以上です。リストのかなり下にあるのは、スペイン語以外の最初の名前「victoria」で、144の都市しかありません。）
次に、私の実装... （それはあなたのものといくつかの類似点があります。）
http://mysql.rjweb.org/doc.php/latlng
これにより、PARTITIONingを使用してパフォーマンスが向上します バウンディングボックスをストライプやウェッジではなく、ほぼ正方形に保つこと。最も近い5つを探している場合、私のアルゴリズムが数十行を超えることはめったになく、それらの行は少数のブロックに「クラスター化」されるため、ディスクヒット数は非常に少なくなります。
私の設計で重要なことは、1つのテーブルに必要なすべての列を含めることです。最も近い5を見つけたら、他のテーブルに移動して補助的なもの（電話番号など）を取得できます。
郵便番号については、最も近い5つの検索を開始する前に、それらをlat/lonに変換してください。
アルゴリズム内で結合すると、パフォーマンスが低下する可能性が非常に高くなります。