1. 概述

这个问题貌似挺简单的，脑子里蹦出很多个解决方案，但是如果有大量的商户的话，这个问题看起来就不是那么好解决了。
前提是，在数据库中记录了各商户的坐标经纬度。

2. 设计

2.1 按照题纲来处理

在数据库找出所有数据，然后再计算出对应条目的经纬度与当前定位经纬度的距离，再按照距离排序。

显然这是一个土办法，是一个 磁盘IO密集型 + CPU密集型 的办法，如果数据库有100万条数据，甚至更多的话，计算每一个条目与定位的距离，再进行距离排序，太耗费时间了，响应时间可能要超过10秒。淦！

2.2 分析题纲

然而这其实是一个伪需求，因为业务上来说，按距离查询应该要给出一个范围，比如广州市内，或者最近1km，2km，3km，10km等。不然按距离查询出来的意义在哪？

对了，也可能是导出数据，这有点牵强，但若真的是导出数据的话，可以通过定时脚本任务。

因此，合理情况下，应该加个距离范围筛选，那么怎么筛选？

2.2.1 方案一

如果范围是广州市内，那么很简单，直接筛选出商户数据的 city 字段是广州的数据就可以了。这样真的就可以了吗？还有排序呢！

  1. 如果找出所有数据，再到代码里面计算距离，再进行排序，是一个方案。
  2. 那么可以在数据库做排序吗，貌似也可以。只需要将计算距离的逻辑写入到查询内，然后 order by 也可以。

    2.2.2 方案二

    如果筛选条件是按距离筛选，可以按照方案二的 b. 来处理，但是如果一个范围内的数据仍然过多的话，查询出来响应时间还是不能容易接受，那么有更好的办法吗？
    有的！
    如果我们能先找到一个范围内的数据条目再进行距离计算，和排序，那将能过滤掉更多不用的计算数据。那应该怎么找到这个范围的数据呢，即使不是很精确。
    这里我们需要考虑到如果要减少查询压力，应该尽可能不要有计算在里边。数据库的字段是按照经纬度存储的，那么我们可以筛选出某个经纬度范围的数据，比如：a1 > 经度 > a2，b1 > 维度 > b2，然后再在计算距离筛选和排序。