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))
<p>注意：<code>POINT(longitude, latitude)</code> 参数顺序是经度在前、纬度在后，反了会得到荒谬距离；<code>ST_Distance_Sphere</code> 单位是米，别误当成公里。</p>
<h3>PostgreSQL + PostGIS 必须用 <code>ST_DWithin</code> 配合 <code>geography</code> 类型</h3>
<p><code>ST_DWithin</code> 是唯一能走空间索引的距离谓词，硬写 <code>ST_Distance</code> 会全表扫描。但前提是字段必须是 <code>geography</code> 类型（不是 <code>geometry</code>），否则单位是度，数值毫无意义：</p>
- 建表时定义：
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')
空间索引对查询条件里的“中心点”无感，只加速“字段本身”的范围筛选；如果你的分组依赖多个动态中心点（比如每个商户算自己周边），单索引无法复用，得考虑预计算或缓存。
