首先得提个小细节：你写的SQL里longitude between (client.location.longitude + 0.1) and (client.location.longitude - 0.1)顺序搞反了——between要求左值小于等于右值，不然这个条件会直接返回空结果，正确写法应该是longitude between (client.lon - 0.1) and (client.lon + 0.1)，纬度同理，先把这个小bug修正再谈效率。

数千条数据时的效率表现 #

如果你的表没有任何索引，数千条数据的全表扫描在MySQL里其实跑得很快——毕竟数据量不大，哪怕逐行过滤经纬度范围，耗时大概也在几十毫秒以内，基本不会有明显的性能问题。但这个方案扩展性很差，等数据量涨到几万、几十万时，全表扫描的耗时会直线上升。

如果已经给longitude和latitude加了索引（不管是单独索引还是复合索引），查询效率会提升不少：MySQL可以通过索引快速定位符合经度范围的行，再过滤纬度条件，避免全表扫描。不过单字段索引在双范围条件下，通常只能用到其中一个区分度更高的字段索引；复合索引的效果会更优。

可行的优化方式 #

1. 修正SQL逻辑并添加复合索引 #

先把SQL的范围顺序修正后，创建复合索引：

CREATE INDEX idx_lon_lat ON addresses (longitude, latitude);

查询时，MySQL会先通过longitude的范围快速缩小数据集，再在这个小范围内过滤latitude条件，比单字段索引或无索引的效率高很多。如果业务里纬度的区分度更高，也可以把latitude放在复合索引的前面。

2. 改用空间索引与空间函数（推荐） #

经纬度是球面坐标，你原来用±0.1度的范围很不严谨——不同纬度下，1度对应的实际距离差很多（比如赤道上1度≈111km，北纬60度只有≈55km），而且普通范围查询的扩展性差。MySQL支持空间数据类型，这才是处理地理位置查询的正确姿势：

• 先给表添加POINT类型字段存储经纬度：

  ALTER TABLE addresses ADD COLUMN location POINT NOT NULL;
  UPDATE addresses SET location = ST_GeomFromText(CONCAT('POINT(', longitude, ' ', latitude, ')'));
  

• 创建空间索引：

  CREATE SPATIAL INDEX idx_spatial_location ON addresses (location);
  

• 用空间函数查询指定范围的房产（比如客户端位置10公里内）：

  SELECT * FROM addresses
  WHERE ST_Distance_Sphere(location, ST_GeomFromText('POINT(客户端经度 客户端纬度)')) <= 10000;
  

  空间索引的查询效率远高于普通范围索引，尤其是数据量增长到几万、几十万时，还能准确按实际距离筛选，比固定度数范围合理得多。

3. 缓存高频查询结果 #

如果很多用户都在查询同一个区域的房产（比如热门商圈），可以把这些查询结果缓存到Redis之类的缓存系统里，避免重复查询数据库。比如按“客户端位置±X公里”作为缓存key，设置合适的过期时间，既能减轻数据库压力，又能提升响应速度。

4. 数据分区（针对未来扩容） #

如果以后房产数据会增长到几十万甚至几百万条，可以考虑按地理位置分区，比如按经度区间分成几个分区，查询时MySQL只会扫描符合条件的分区，减少需要处理的数据量。不过数千条数据的话，暂时没必要做分区。

内容的提问来源于stack exchange，提问作者Alex