必须为参与空间连接的几何列创建gist索引，否则查询性能从秒级降至分钟级；st_dwithin是唯一能利用索引的距离谓词，且应优先使用geography类型与统一srid（如4326）以确保正确性和性能。
直接用 ST_DWithin 或 ST_Contains 做空间连接时，没加空间索引会导致查询从秒级变成分钟级——这不是数据量问题，是索引缺失。
PostgreSQL/PostGIS 中必须创建 GIST 空间索引
PostGIS 不会自动为 GEOMETRY 或 GEOGRAPHY 列建索引，哪怕你用了 ST_Point(long, lat) 构造坐标也不行。没索引时，每次连接都要全表扫描几何对象，O(n²) 复杂度立刻显现。
实操建议：
- 对参与连接的两个表的地理列都建
GIST索引，例如：CREATE INDEX idx_locations_geom ON locations USING GIST (geom);
- 若用
GEOGRAPHY类型（推荐用于经纬度距离计算），索引语句不变，但类型定义要明确：ALTER TABLE locations ALTER COLUMN geom TYPE GEOGRAPHY(POINT, 4326);
- 建完索引后务必
VACUUM ANALYZE locations，否则查询计划器可能仍不走索引
用 ST_DWithin 而不是手写距离公式
很多人试图用 sqrt((x1-x2)^2 + (y1-y2)^2) 或 Haversine 手算距离再过滤，这既难维护又无法利用空间索引。PostGIS 的 ST_DWithin 是唯一能下推到索引层的距离谓词。
注意点：
-
ST_DWithin(geom1, geom2, distance)中，若列是GEOMETRY，distance单位是投影单位（如 Web Mercator 是米，但失真大）；若为GEOGRAPHY，单位统一为米，且自动按球面计算——绝大多数经纬度场景应选后者 - 不要在
WHERE子句里嵌套ST_Transform，比如ST_DWithin(ST_Transform(a.geom, 3857), ...)，这会让索引失效 - 示例（查 500 米内门店与用户）：
SELECT u.id, l.name FROM users u JOIN locations l ON ST_DWithin(u.geog, l.geog, 500);
避免跨 SRID 比较导致隐式转换失败
常见错误现象：ERROR: Operation on two GEOMETRIES with different SRIDs。哪怕两个字段都是 POINT，只要一个定义为 SRID=4326、另一个是 SRID=0，PostGIS 就拒绝运算，且不会自动转换。
排查和修复：
- 检查字段 SRID：
SELECT Find_SRID('public', 'locations', 'geom'); - 统一 SRID 最稳妥方式是建表时指定：
geom GEOGRAPHY(POINT, 4326)
，而非后期用ST_SetSRID - 如果必须转换，显式用
ST_Transform并确保目标 SRID 有对应空间索引（否则性能归零）
真正卡住性能的往往不是函数选错，而是索引没生效或 SRID 不一致——执行 EXPLAIN 时看不到 Index Scan using xxx on yyy 就得回头查这两项。
