Først nogle kommentarer...
Jeg har set snesevis (ikke millioner) af implementeringer her og på andre fora; din er bedre end de fleste.
Ifølge en datakilde (som jeg tilfældigvis har downloadet) er der omkring 3,2 millioner byer i verden.
For ydeevne skal du undgå at kontrollere alle 3M rækker. Du har fået en god start med den voksende afgrænsningskasse. Bemærk, at du burde have
INDEX(lat, lon),
INDEX(lon, lat)
Optimeringsværktøjet vil vælge mellem disse og den første forespørgsel (med COUNT(*) ) vil se det som 'dækkende'. Det vil være en stribe rundt om kloden eller en kile; en klar forbedring i forhold til 3M rækker. Den værste breddegrad (+34 grader) har 96K byer i sig. (1 grad =69 miles / 111 km.) For en tiendedel af en grad er 34,4 det værste med 10.000 byer.
(Ja, jeg nyder denne form for datapuslespil.)
Og jeg kan se, at du håndterer datolinjen og polerne. Jeg tror ikke, du kan forbedre dig ved at have dem som et særligt tilfælde.
(Jeg har kun kigget på formlerne og konstanterne.)
Geohash og Z-order indeksering hjælper. Men de har et hikke ved, at du skal tjekke op til 4 områder omkring målet -- Det er ligesom ikke at indse, at heltal 199999 og 200000 er virkelig tæt på hinanden, på trods af at det første ciffer af hver er anderledes.
"Brugeren indtaster postnummer eller bynavn" - det er en punktforespørgsel i en af to simple tabeller. (Undtagen at der kan være dups -- over 320 hver af "san jose" og "san antonio". Temmelig langt nede på listen er det første ikke-spanske navn:"victoria", med kun 144 byer.)
For det andet min implementering... (Den har nogle ligheder med din.)
http://mysql.rjweb.org/doc.php/latlng
Dette forbedrer ydeevnen ved at bruge PARTITIONing at holde afgrænsningsrammen nede på nogenlunde en firkant i stedet for en stribe eller kile. Hvis du leder efter de 5 nærmeste, vil min algoritme sjældent røre mere end et par dusin rækker, og disse rækker vil blive 'grupperet' i et lille antal blokke, og derved holde antallet af diskhits meget lavt.
En kritisk ting i mit design er at have alle de nødvendige kolonner i den ene tabel. Når du har fundet de nærmeste 5, kan du gå til andre borde for at få hjælpeting (telefonnummer osv.).
Hvad angår postnumre, skal du omdanne dem til lat/lon, før du starter søgningen efter de 5 nærmeste.
En joinforbindelse inde i algoritmen vil med stor sandsynlighed ødelægge ydeevnen.