有谁知道数据库结构，例如这个http://www.maxmind.com/app/geolitecity，它针对基于 ZIP 或（城市、州、国家）参数的经纬度超快速检索进行了优化？
Maxmind 的数据库不支持 IP 检索以外的任何其他检索，至少不支持挖掘知识。因此，如果您知道如何最好地在 Java 中做到这一点，我会全力以赴。
这不应该是 SQL 类型的数据库或 CSV 文件或 Google API 解决方案。你只是要慢一点。特别是如果您想提供按距离排序的搜索结果。
付费解决方案也是一种选择。数据结构不必是免费的。
我不相信有这样一种“快速”的方式来做到这一点。我已经为加拿大邮政编码构建了一个地理编码 API，我们搜索的方式是有两个邮政编码索引——一个按纬度排序，一个按经度排序。您可以做一些球面几何并开发一个边界“框”，以适应给定半径内的所有内容，但您仍然必须返回并使用 Vincenty 或 Haversine 或您选择的算法来进行点对点距离测量，以计算原点之间的距离以及您找到的每个邮政编码。
借助全球数据库，您可以穿越经线和赤道，从而使您的数学变得复杂。
您将需要某种可以让您以弧度工作的编码方案，因为这是大多数距离计算启发式所需要的。
这可以通过任何支持二维索引的数据库引擎快速完成……据我所知，mysql 支持无限维度……这很简单……您使用二维索引将结果集限制在合理的范围内大小非常快...然后如果您需要，您可以使用高精度计算算法检查您的结果集.. 不难.. 除非您可能需要或两个列表一起穿过 180/-180 经度线制作 2d索引很简单....索引（纬度，经度）...该索引仅适用于纬度或纬度，经度对...它不适用于单独的经度...如果您想要一个额外的经度索引索引（经度）....如果我关心它们，我会选择一个粗略的估计正方形和圆角。...
如果你有一个邮政编码或城市开始......邮政编码只是一个一维索引......没有问题让它快速发生......只需使用索引索引（zip）......如果你的硬盘驱动器是太慢了，买一个固态驱动器来消除寻道时间..或者使用一个巨大的内存来缓存整个表......无论你想怎么做，这都不是一个难题
如果这对您来说还不够快，那么使用某人的服务将无济于事，因为您有网络开销……您必须将数据直接保存在 ram/ssd 中并构建自己的二维/一维索引系统需要它（不难）...该路由可能会以 10 倍左右的速度击败 sql，因为 sql 引擎有很多开销...。我想有人可能会提供在您自己的机器上运行的服务，但是实际上，这不会远远超过 sql，因为您仍然必须通过一堆 hoopdiloops 才能向他们的服务发出请求。带有固态驱动器的 sql 和 2-d 索引将非常快，除非您是邮局，否则您不需要自己处理数据，使用一台提供数据的机器每秒分拣 10,000 封邮件。那么你'