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(...) < 1000——这会禁用索引，改用ST_DWithin(..., 1000)
• 如果A表也很大，考虑分批处理（比如按行政区ID分组），避免单次JOIN爆炸

地理距离JOIN的真实瓶颈不在语法，而在是否让数据库知道“先缩小搜索范围，再精确算距”。漏掉ST_DWithin预过滤，或误用geometry代替geography，基本就等于白忙。