ST_Distance 不触发空间索引，因其仅为纯计算函数；即使 geom 字段已建 GEOGRAPHY 类型及 GIST 索引，WHERE 中直接使用仍无法利用索引加速。
ST_Distance 计算两点距离时为什么慢得像没建索引？
因为 ST_Distance 本身不触发空间索引——它只是个纯计算函数，哪怕你对经纬度字段加了 GEOGRAPHY 类型和 GIST 索引，写 WHERE ST_Distance(a.geom, b.geom) 也会全表扫描。
真正能走索引的是范围谓词，比如 ST_DWithin 或 &&（边界框相交）。必须先用它们粗筛，再用 ST_Distance 精算。
- PostGIS 中，
ST_DWithin(geom1, geom2, distance)自动利用空间索引，且支持GEOMETRY（平面米）和GEOGRAPHY（球面米）两种单位语义 - 若用
GEOMETRY存 WGS84 坐标（如 EPSG:4326），ST_DWithin默认按“度”算，结果不准；必须显式转GEOGRAPHY或指定use_spheroid:=true - 常见错误：写成
ST_DWithin(a.geom::geography, b.geom::geography, 1000)却忘了给a.geom和b.geom字段本身建GIST索引——类型转换后索引失效，得建在转换后的表达式上，或直接存为GEOGRAPHY
怎么让 JOIN 基于 5km 内的地理位置关联？
别直接 ON ST_Distance(a.loc, b.loc) ，改用两步：先 <code>ST_DWithin 快速过滤候选对，再用 ST_Distance 排序或筛选精确值。
SELECT a.id AS a_id, b.id AS b_id, ST_Distance(a.loc::geography, b.loc::geography) AS dist_m FROM places a JOIN places b ON ST_DWithin(a.loc::geography, b.loc::geography, 5000) WHERE a.id != b.id;
注意：ST_DWithin 的第三个参数单位是米（当输入为 GEOGRAPHY），不是公里；如果字段是 GEOMETRY 类型且坐标系是 EPSG:4326，必须写成 ST_DWithin(a.loc, b.loc, 5000, true) 才启用球面计算，否则结果偏差可达几十公里。
- 索引必须匹配查询类型：若常用
::geography，就在原字段上建USING GIST ((loc::geography))表达式索引 - JOIN 结果量可能爆炸（n² 级），加
LIMIT或提前用WHERE限定一侧主表范围（如只查某城市内的点） - 若只要每个
a最近的一个b，用ORDER BY ST_Distance(...) LIMIT 1配合LATERAL更高效
为什么 ST_Distance 返回值忽大忽小，和实际地图距离对不上？
核心就一个原因：坐标类型与单位混淆。ST_Distance 对 GEOMETRY 返回“度”，对 GEOGRAPHY 才返回“米”。WGS84 下 1 度 ≈ 111km（赤道），但随纬度升高，经度方向距离急剧缩小——所以直接比 ST_Distance(geom, geom) 完全不可靠。
- 检查字段类型：
SELECT geometrytype(loc), st_srid(loc) FROM places LIMIT 1，确认是否为SRID 4326且期望语义是球面距离 - 统一转
GEOGRAPHY：所有距离计算前加::geography，包括ST_DWithin和ST_DDistance - 避免隐式转换：PostgreSQL 可能自动 cast，但行为不稳定；显式声明更安全
空间索引建了还是慢？可能是这些细节漏了
建了 GIST 索引不等于万事大吉。PostGIS 查询性能卡点常在数据分布和统计信息上。
- 运行
VACUUM ANALYZE places，确保查询规划器知道几何列的数据分布，否则可能弃用索引选全表扫描 - 检查索引是否真的被用上：
EXPLAIN (ANALYZE, BUFFERS) SELECT ...，看执行计划里有没有Index Scan using ...，而不是Seq Scan - 若表中大量
NULL几何值，索引效率下降；考虑加WHERE loc IS NOT NULL过滤 - 高并发下
GIST索引页争用可能成为瓶颈，这时可考虑分区（如按城市、区域分表）或降采样预过滤
最易忽略的一点：空间索引只加速“是否相交/是否在范围内”这类判断，不加速排序。想按距离排序取 Top-N，仍需计算全部候选距离值——这时候 LATERAL + LIMIT 比全量 JOIN 更可控。
