@Baron
I think it’s not the best advice to completely avoid MyISAM tables in production as long as there are features that can not be reproduced by any other SE. You must know what data is business critical (for example user information) and treat it like your eyeball. Anything else which can be obtained within minutes (where I would see such a GEO-cache table) could also rest in a relativeley “insecure” table type.

1) MySQL

2) Regular B-Tree. It’s hard to give a meaningful description of the performance other than to say the query almost always takes just a few milliseconds, assuming the server isn’t heavily loaded from other queries. Since the app (these are telephone-based speech recognition applications) is presenting a list to the user, it doesn’t make sense to use a radius that will return a huge list, since people are rarely interested in hearing about more than the first 10 or so locations. The majority of the time, they don’t go past the first window of 3 locations. The main exception would be one of our hotel locators when the user is searching in a large city. Even then, the query time is a relatively small fraction of the total time to generate the list.

3) Float

1) Which database are you using? MySQL?

2) How about the performance of the range query on latitude, longitude? I’m assuming the composite index is a regular B-tree (not spatial).

3) What datatype/precision do you use to store latitude and longitude?

Thanks!