sql server中stdistance单位为米，需用geography::point(经度,纬度,4326)构造点；postgresql+postgis需显式转geography或用st_distancesphere；mysql必须用st_distance_sphere。
SQL Server里用STDistance计算两点距离，单位是米
SQL Server的GEOGRAPHY类型自带球面距离计算，比用Haversine公式手动算更准、更简。关键前提是：坐标必须按POINT(经度 纬度)顺序传入（注意——经度在前，和常见“纬度,经度”直觉相反），且SRID要统一为4326。
常见错误现象：STDistance返回NULL，大概率是点构造失败（比如经纬度反了、超出范围）或SRID不匹配；返回值异常小（如0.001），可能是误用了GEOMETRY类型（平面距离，单位取决于坐标系）。
- 构造点必须用
geography::Point(经度, 纬度, 4326)，例如北京天安门：geography::Point(116.403973, 39.915119, 4326) - 两点
STDistance结果单位固定为米，无需额外换算 - 若原始数据存的是
float字段，构造前建议用CAST确保精度，避免隐式转换截断
PostgreSQL+PostGIS用ST_Distance，注意单位和SRID
PostgreSQL本身不原生支持地理距离，得靠PostGIS扩展。它默认返回的是“空间参考单位”，对WGS84（SRID=4326）来说，单位是度——不能直接当公里用。必须显式要求地理计算（geography类型）或用ST_DistanceSphere/ST_DistanceSpheroid。
容易踩的坑：写ST_Distance(a.geom, b.geom)却没指定类型，结果是平面欧氏距离（无意义）；或者忘了ST_SetSRID，导致函数按SRID=0处理，距离完全不准。
- 推荐写法：
ST_Distance(a.geog::geography, b.geog::geography)，其中geog是已设SRID=4326的geography列 - 如果只有
geometry列，用ST_DistanceSphere(ST_SetSRID(ST_MakePoint(lon, lat), 4326), ...) -
ST_DistanceSpheroid精度更高但慢，日常用ST_DistanceSphere足够
MySQL 5.7+用ST_Distance_Sphere，别碰ST_Distance
MySQL的ST_Distance只支持平面计算，对地理坐标会得出荒谬结果（比如上海到北京算出几百米）。必须用ST_Distance_Sphere，它强制按球面算，单位是米，且自动适配WGS84椭球模型。
使用场景受限：该函数要求两个参数都是POINT，且必须用ST_GeomFromText('POINT(经度 纬度)')构造（同样，经度在前），不能直接传数值字段。
- 正确示例：
ST_Distance_Sphere(ST_GeomFromText(CONCAT('POINT(', t.lon, ' ', t.lat, ')'), 4326), ST_GeomFromText('POINT(116.403973 39.915119)', 4326)) - 如果表中已有
POINT列且已设SRID，可直接用：ST_Distance_Sphere(point_col, ST_GeomFromText('POINT(...)', 4326)) - 性能提示：该函数无法走空间索引，大数据量务必先用
ST_Contains(ST_Buffer(...), ...)粗筛
跨数据库兼容性差，别指望一个SQL跑通所有库
三个主流数据库的地理距离函数名、参数顺序、单位、SRID处理逻辑全都不一样。想写通用SQL？基本不可行。最现实的做法是：在应用层抽象出“计算距离”接口，数据库方言由DAO或ORM适配。
容易被忽略的地方：很多业务只要“是否在5公里内”这种布尔判断，其实没必要算精确距离——用ST_DWithin（PostGIS）、ST_Within配合ST_Buffer（SQL Server/MySQL）做半径过滤，能利用空间索引，性能提升数量级。
