ST_DWithin是最稳妥的空间关联方案，能走GIST索引避免全表扫描；要求两表坐标系一致（如EPSG:4326）、字段类型为GEOMETRY或GEOGRAPHY、均已建空间索引；GEOGRAPHY类型下第三参数单位为米，更直观准确。
PostgreSQL + PostGIS 怎么用 ST_DWithin 关联两个带坐标的表
直接用 ST_DWithin 是最稳妥的方案，它能走空间索引，避免全表扫描。前提是两个表的地理字段都建了 GIST 索引，且坐标系一致（比如都是 EPSG:4326）。
常见错误是把经纬度当普通数值用 sqrt(pow(...)) 手算距离——不仅慢，还因地球曲率导致 1km 以内误差可达几十米；更糟的是完全无法利用索引，10 万行以上基本卡死。
- 确保字段类型是
GEOMETRY或GEOGRAPHY：用ST_Point(long, lat)转换，注意参数顺序是「经度在前、纬度在后」 - 索引必须显式创建：
CREATE INDEX idx_locations_geom ON locations USING GIST (geom); -
ST_DWithin第三个参数单位取决于类型：用GEOMETRY时单位是「投影坐标系的单位」（如 Web Mercator 是米，但 EPSG:4326 是度，不推荐）；用GEOGRAPHY时单位直接是「米」，更直观 - 示例关联语句：
SELECT a.id, b.name, ST_Distance(a.geom::GEOGRAPHY, b.geom::GEOGRAPHY) AS dist_m FROM shops a JOIN cities b ON ST_DWithin(a.geom::GEOGRAPHY, b.geom::GEOGRAPHY, 5000);
（查 5km 内最近城市）
MySQL 8.0 的 ST_Distance_Sphere 能不能用于 JOIN 条件
不能直接用于 ON 做高效关联。虽然 ST_Distance_Sphere 计算准确（返回米），但它是个标量函数，MySQL 无法基于它下推空间过滤，执行计划里会显示 type: ALL，即全表扫描。
真正能走索引的是 MBRContains 或 ST_Contains 这类矩形包围盒（MBR）操作，但它们只做粗筛——先用 MBR 快速排除明显远的，再用 ST_Distance_Sphere 精筛。
- 必须给地理字段加空间索引：
ADD SPATIAL INDEX idx_coord ON places (coord);（coord是POINT类型） - 两步写法示例：
SELECT p1.id, p2.name, ST_Distance_Sphere(p1.coord, p2.coord) AS d FROM places p1 JOIN places p2 ON MBRContains(ST_Buffer(p1.coord, 0.05), p2.coord) WHERE ST_Distance_Sphere(p1.coord, p2.coord) <= 5000;
（0.05是约 5km 的纬度粗略偏移，用于构造搜索矩形） - 注意
ST_Buffer在 MySQL 中对POINT生成的是圆心矩形，不是真圆，但足够做初筛
SQL Server 的 STDistance 为什么总报「不支持 geography 类型」
大概率是字段定义成了 geometry 而非 geography。SQL Server 严格区分两者：geometry 是平面坐标，STDistance 返回单位是「坐标系单位」（如 WGS84 下是度）；geography 才支持球面计算，返回单位是米。
另一个坑是 SRID 不匹配：两个 geography 实例必须有相同 SRID（通常是 4326），否则 STDistance 直接抛错 Operand types do not match。
- 检查类型：
SELECT TOP 1 coord.STSrid, coord.InstanceOf() FROM locations;（应返回4326和Geography） - 转换语句：
ALTER TABLE locations ALTER COLUMN coord TYPE geography USING coord::geography;（PostgreSQL 语法示意，SQL Server 需先添加新列再更新） - 索引要求：SQL Server 要求空间索引必须是
geography类型，且网格层级设为MEDIUM或更高才能有效加速STDistance
没空间扩展的 SQLite 怎么近似算距离
SQLite 原生不支持地理类型，但可以用 Haversine 公式手动算球面距离，配合普通 B-tree 索引做有限优化——比如先按经度范围粗筛（WHERE lng BETWEEN ? AND ?），再在子查询里算精确距离。
性能瓶颈明显：10 万行数据，即使加了经纬度复合索引，每条主表记录仍要遍历数千候选，响应常超 2 秒。不适合实时接口，仅适用于离线批量或小数据集。
- Haversine 表达式（SQLite 支持
sin/cos/acos）：SELECT id, name, 6371 * acos( sin(?) * sin(lat) + cos(?) * cos(lat) * cos(lng - ?) ) AS dist_km FROM places WHERE lng BETWEEN ? AND ? AND lat BETWEEN ? AND ? ORDER BY dist_km LIMIT 10;（?是用户坐标和搜索半径对应的经纬度边界） - 经度边界计算不可省：用
lon ± radius_km / (111.32 * cos(lat_radians))，否则高纬度地区漏结果 - 别指望
ORDER BY dist_km LIMIT 1走索引——SQLite 无法对表达式下推索引，只能靠前面的BETWEEN缩小范围
空间索引不是银弹：PostGIS 的 GEOGRAPHY 索引在跨国际日期变更线或极点附近会失效；MySQL 的 MBR 筛选在长条状区域（如河流、公路）容易多捞；SQL Server 对大范围（>1000km）的 STDistance 查询可能退化。实际用时得结合业务场景压测真实数据分布。
