SQL如何实现基于地理位置的分组统计？

MySQL 5.7+ 中 ST_Distance_Sphere 不能直接用于 GROUP BY 分组，因浮点精度导致区间分裂；应先用 CASE WHEN 或 FLOOR 归类距离段（如 ‘0-5km’），再 GROUP BY；务必确保 POINT(longitude, latitude) 顺序正确且单位为米，并为 POINT 字段建立 SPATIAL INDEX。

MySQL 5.7+ 的 ST_Distance_Sphere 能直接算球面距离，但不能直接用于 GROUP BY

想按“离某点5km内”“10km内”分组统计用户数？别直接在 GROUP BY 里写 ST_Distance_Sphere —— 它返回浮点数，精度误差会导致相同距离区间被拆成多个微小差异的分组。正确做法是先用 CASE WHEN 或 FLOOR 归类距离段，再分组：

SELECT 
  CASE 
    WHEN ST_Distance_Sphere(point, POINT(-73.9857, 40.7484)) < 5000 THEN '0-5km'
    WHEN ST_Distance_Sphere(point, POINT(-73.9857, 40.7484)) < 10000 THEN '5-10km'
    ELSE '10km+'
  END AS distance_range,
  COUNT(*) AS user_count
FROM users
GROUP BY distance_range;

注意：POINT(longitude, latitude) 参数顺序是经度在前、纬度在后，反了会得到荒谬距离；ST_Distance_Sphere 单位是米，别误当成公里。

PostgreSQL + PostGIS 必须用 ST_DWithin 配合 geography 类型

ST_DWithin 是唯一能走空间索引的距离谓词，硬写 ST_Distance 会全表扫描。但前提是字段必须是 geography 类型（不是 geometry），否则单位是度，数值毫无意义：

• 建表时定义：location GEOGRAPHY(POINT, 4326)
• 查询时显式转类型也行：ST_DWithin(location::GEOGRAPHY, ST_GeogFromText('POINT(-73.9857 40.7484)'), 5000)
• WHERE 条件里用 ST_DWithin，GROUP BY 仍需配合 CASE 或生成距离桶

漏掉 ::GEOGRAPHY 强转或用错 SRID，ST_DWithin 可能返回空结果却不报错——这是最常踩的静默坑。

SQLite Spatialite 的 ST_Distance 默认用平面坐标，实际距离严重失真

Spatialite 的 ST_Distance 对 POINT 默认按平面欧氏距离算，赤道上1度≈111km，高纬度地区同样1度可能只有50km。不修正就分组，北方城市统计结果会系统性偏小：

• 必须用 ST_Distance(SRID=4326, ...) 显式指定地理坐标系
• 或者改用 ST_DistanceSphere（Spatialite 5.0+）
• 验证方法：查已知两点（如北京到上海），看返回值是否接近1000km级而非10°级

很多旧项目还在用没升级的 Spatialite，ST_Distance 返回值看着像距离，其实是角度差——这个误解会让分组阈值完全失效。

性能关键：所有数据库都必须给地理字段加空间索引

没索引时，哪怕只查1000条记录，ST_Distance_Sphere 或 ST_DWithin 也会触发全表计算，响应从毫秒变秒级。索引语法各异，但漏掉这步，前面所有逻辑都白搭：

• MySQL：SPATIAL INDEX(point)（字段类型必须是 POINT）
• PostGIS：CREATE INDEX idx_users_location ON users USING GIST (location)
• Spatialite：SELECT CreateSpatialIndex('users', 'location')

空间索引对查询条件里的“中心点”无感，只加速“字段本身”的范围筛选；如果你的分组依赖多个动态中心点（比如每个商户算自己周边），单索引无法复用，得考虑预计算或缓存。