st_distance地理距离join结果不准，是因为默认按平面坐标系计算，单位为“度”而非米；必须将参数显式转为geography类型（如st_distance(a.geom::geography, b.geom::geography)）或使用st_distancesphere，才能获得以米为单位的准确球面距离。
用ST_Distance做地理距离JOIN时为什么结果不准
PostgreSQL的ST_Distance默认用平面坐标系（如SRID 4326下不显式指定单位），直接算出的数值是“度”，不是米，导致排序完全失真。必须强制转成地理类型（geography）或指定大地测量函数。
- 错误写法：
ST_Distance(a.geom, b.geom)—— 返回度，无法跨纬度比较 - 正确写法：
ST_Distance(a.geom::geography, b.geom::geography)—— 返回米 - 或者用
ST_DistanceSphere/ST_DistanceSpheroid，但性能略差
如何对每个A点找最近的B点（1:N最近邻）
不能简单ORDER BY ST_Distance(...) LIMIT 1后JOIN，那样会丢失A点——得用LATERAL子查询或窗口函数。LATERAL更直观、可读性高，且PostgreSQL 9.3+原生支持。
- 核心结构：
LATERAL (SELECT * FROM b ORDER BY ST_Distance(a.geom::geography, b.geom::geography) LIMIT 1) - 注意：B表要有
GIST索引在geom列上，否则LATERAL会全表扫描，极慢 - 如果B表很大，加
WHERE ST_DWithin(a.geom::geography, b.geom::geography, 5000)先圈定5km内候选，再排序，能显著提速
SELECT a.id, b.id AS nearest_b_id,
ST_Distance(a.geom::geography, b.geom::geography) AS dist_m
FROM places_a a
LATERAL (
SELECT id, geom
FROM places_b b
WHERE ST_DWithin(a.geom::geography, b.geom::geography, 5000)
ORDER BY ST_Distance(a.geom::geography, b.geom::geography)
LIMIT 1
) b;
MySQL或SQL Server怎么处理类似需求
MySQL 8.0+支持ST_DistanceSphere，但没LATERAL，只能用相关子查询+ORDER BY ... LIMIT 1嵌套，性能较差；SQL Server要用TOP 1 WITH TIES配合APPLY（等价于LATERAL），且必须用geography::Point构造点。
- MySQL示例：
(SELECT id FROM b ORDER BY ST_DistanceSphere(a.point, b.point) LIMIT 1)—— 没索引加速，大数据慎用 - SQL Server关键点：确保字段是
geography类型，不是geometry；STDistance()才返回米 - 所有非PostGIS方案都缺乏
ST_DWithin预过滤能力，容易OOM或超时
为什么加了索引还是慢？常见性能陷阱
即使建了GIST索引，ST_Distance本身无法利用索引排序——它只是计算函数。真正起作用的是ST_DWithin的范围过滤和ORDER BY中隐含的索引扫描顺序。
- 必须为B表的
geom列建USING GIST (geom)索引，且该列类型为geometry或geography - 不要在
ON条件里写ST_Distance(...) ——这会禁用索引，改用<code>ST_DWithin(..., 1000) - 如果A表也很大，考虑分批处理（比如按行政区ID分组），避免单次JOIN爆炸
地理距离JOIN的真实瓶颈不在语法，而在是否让数据库知道“先缩小搜索范围，再精确算距”。漏掉ST_DWithin预过滤，或误用geometry代替geography，基本就等于白忙。
