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