必须用 ST_Distance_Sphere 计算经纬度距离，因其按球面计算、单位为米；ST_Distance 默认按平面欧氏距离计算、单位为度，会导致结果严重失真。
MySQL 8.0+ 中用 ST_Distance_Sphere 批量更新最近的 POI
直接结论：别用 ST_Distance 做经纬度距离计算，它默认按平面欧氏距离算，单位是“度”，结果完全失真；必须用 ST_Distance_Sphere，它才按地球球面算，返回单位是米。
常见错误现象是：你明明给了一组用户坐标和一批门店坐标，执行 UPDATE ... JOIN 后，每个用户都绑到了同一个远在 500km 外的“最近”门店——因为 ST_Distance 把纬度差 1° 当成和经度差 1° 等价，而赤道上 1° 经度 ≈ 111km，到北纬 60° 就只剩 ≈ 55km，偏差直接翻倍。
实操建议：
- 确保两个坐标字段都是
POINT类型，且 SRID = 4326（WGS84），例如：ALTER TABLE users MODIFY location POINT SRID 4326; - JOIN 时用子查询先算最小距离，避免 MySQL 在 UPDATE 中不支持窗口函数的问题
- 加
WHERE ST_Distance_Sphere(u.location, p.location) 过滤掉明显超距的匹配，能大幅提速
示例（给 users 表批量更新最近的 poi_id）：
UPDATE users u
JOIN (
SELECT u.id AS uid,
p.id AS poi_id,
ROW_NUMBER() OVER (PARTITION BY u.id ORDER BY ST_Distance_Sphere(u.location, p.location)) AS rn
FROM users u
CROSS JOIN pois p
WHERE ST_Distance_Sphere(u.location, p.location) <= 50000
) ranked ON u.id = ranked.uid AND ranked.rn = 1
SET u.poi_id = ranked.poi_id;
PostgreSQL + PostGIS 用 LATERAL 实现高效批量地理更新
PostgreSQL 的优势在于原生支持 LATERAL，可以为每一行用户实时关联 TOP 1 最近 POI，不用全量笛卡尔积，性能差距可达 10 倍以上。
容易踩的坑：
- 忘记给
geography字段建 GIST 索引，ST_DWithin和ORDER BY ST_Distance会全表扫描 - 误用
geometry类型代替geography：前者不自动处理球面距离，必须显式用ST_Transform转投影，极易出错 -
ST_Distance对geography返回米，对geometry返回“当前坐标系单位”，混用会导致数值荒谬
实操写法（假设 users.loc 和 pois.geog 都是 geography(POINT,4326)）：
UPDATE users u
SET poi_id = nearest.poi_id
FROM (
SELECT u2.id AS uid,
(SELECT p.id
FROM pois p
WHERE ST_DWithin(u2.loc, p.geog, 50000)
ORDER BY u2.loc <-> p.geog
LIMIT 1) AS poi_id
FROM users u2
) nearest
WHERE u.id = nearest.uid AND nearest.poi_id IS NOT NULL;
SQL Server 中 STDistance 单位陷阱与索引强制提示
SQL Server 的 STDistance 对 geography 类型返回单位是“米”，看似友好，但默认不走空间索引——尤其在批量 UPDATE 场景下，执行计划常退化为 Nested Loop + 全表扫描，万级用户就卡死。
关键动作只有两个：
- 必须在
geography列上建空间索引，且网格层级设为MEDIUM或更高（LOW对 10km 内搜索基本无效） - UPDATE 中强制 hint 使用索引：
WITH (INDEX(spatial_index_name))，否则优化器大概率忽略它
典型错误写法：UPDATE u SET poi_id = p.id FROM users u, pois p WHERE u.loc.STDistance(p.geog) = (SELECT MIN(u2.loc.STDistance(p2.geog)) ...) —— 这种写法根本没法用索引，纯 CPU 暴力算。
推荐结构（用 APPLY 替代 JOIN 提升可控性）：
UPDATE u SET poi_id = p.poi_id FROM users u CROSS APPLY ( SELECT TOP 1 p2.id AS poi_id FROM pois p2 WITH (INDEX(IX_pois_geog)) WHERE u.loc.STDistance(p2.geog) <= 50000 ORDER BY u.loc.STDistance(p2.geog) ) p;
批量更新前必须验证的三件事
地理批量更新不是普通 UPDATE，失败往往静默发生：没报错，但数据全错。上线前务必确认：
- 所有坐标是否真实落在有效范围内？纬度必须 ∈ [-90,90]，经度 ∈ [-180,180]；出现
999.999或0,0默认值会污染整个距离计算 - 数据库是否开启严格模式？MySQL 的
sql_mode缺少STRICT_TRANS_TABLES时，非法坐标插入会静默转成NULL，后续ST_Distance_Sphere(NULL, ...)返回NULL，UPDATE 不生效也不报错 - 是否测试过边界 case？比如用户刚好在两门店等距线上，不同数据库对
ORDER BY ... LIMIT 1的稳定性处理不同，PostgreSQL 可能每次选不同结果，需加id二次排序兜底
真正麻烦的从来不是函数怎么写，而是坐标质量、索引状态、单位一致性这三块拼图缺一不可。
