PostGIS空间函数返回空结果或报错的主因是SRID未对齐和几何类型未转换：需用ST_SetSRID指定源数据SRID，ST_GeomFromText转WKT，ST_Transform统一坐标系；ST_Within要求a完全在b内，相交应选ST_Intersects；批量处理宜用JOIN而非循环，配合GIST索引与bbox过滤提升性能。
PostGIS 的 ST_Within 和 ST_Intersects 为什么返回空结果
常见现象是写完存储过程调用 ST_Within 却总返回 FALSE 或空集，尤其当输入是 WKT 字符串或普通坐标字段时。根本原因不是函数写错，而是没做坐标系对齐和几何类型转换。
- 必须显式用
ST_SetSRID指定源数据的 SRID（比如ST_SetSRID(ST_Point(lon, lat), 4326)），否则 PostGIS 默认按 0 处理，所有空间关系判断失效 - WKT 字符串要用
ST_GeomFromText转成 geometry，不能直接传字符串给ST_Within - 两个参与比较的 geometry 必须在同一个 SRID 下——用
ST_Transform统一到目标坐标系（如 3857 适合 Web 地图，4326 适合 GPS 原始数据） - 注意
ST_Within(a, b)要求 a 完全落在 b 内部；如果只是相交，该用ST_Intersects，别硬套
在 PostgreSQL 存储过程中批量处理多边形叠加分析
想让存储过程自动把用户上传的点表和行政区划表做归属统计（比如“每个区有多少个门店”），关键不在循环，而在避免逐行调用空间函数带来的性能雪崩。
- 别在
FOR rec IN SELECT ... LOOP里反复执行ST_Within—— 改用单次 JOIN：SELECT d.name, COUNT(*) FROM points p JOIN districts d ON ST_Within(p.geom, d.geom) GROUP BY d.name - 确保
geom字段有空间索引：CREATE INDEX idx_points_geom ON points USING GIST (geom)，否则 JOIN 会全表扫描 - 若点表和面表都很大，先用
ST_Expand+&&做 bbox 快速过滤，再进精确判断，能省掉 70%+ 的计算量 - PostGIS 3.0+ 支持
ST_ClusterDBSCAN，如果目标是聚类而非归属，直接在 SELECT 里用它比写循环快得多
存储过程里调用 ST_Distance 报错 “Operation on two GEOMETRIES with different SRIDs”
错误信息里明确写了 SRID 不一致，但很多人只盯着两个 geometry 变量，忽略了隐式转换带来的陷阱。
- 哪怕两个字段都是
geometry类型，只要一个来自ST_MakePoint(116, 39)（无 SRID），另一个来自表中带 4326 的列，就会报这个错 - 安全写法是统一强制转：
ST_Distance(ST_Transform(a.geom, 3857), ST_Transform(b.geom, 3857))，别依赖自动推断 - 如果只是想算球面距离（单位米），直接用
ST_DistanceSphere或ST_DistanceSpheroid，它们内部自动处理 WGS84，不依赖字段 SRID - 注意
ST_Distance返回的是投影单位（如米），而ST_DistanceSphere返回的是真实球面距离（米），数值可能差 0.1%~0.3%，别混用作阈值判断
如何让 GIS 存储过程在低配数据库上不卡死
空间运算吃内存和 CPU，存储过程一旦嵌套多层、又没设限，很容易触发 PostgreSQL 的 work_mem 溢出或超时中断。
- 在存储过程开头加
SET LOCAL work_mem = '64MB'，避免被全局配置拖累；但别设太高，否则并发一多就 OOM - 用
ST_SimplifyPreserveTopology对输入面做轻度简化（tolerance设 0.001 左右），能显著加快ST_Within判断速度，且不影响业务精度 - 避免在循环里反复执行
ST_Union合并大量 geometry——改用array_agg收集，最后一次性ST_Union(ARRAY[...]) - PostgreSQL 12+ 支持
MATERIALIZEDCTE，对中间结果集加物化，防止优化器重算多次，对复杂空间 JOIN 很有用
空间索引是否生效、SRID 是否显式声明、work_mem 是否局部隔离——这三个点漏掉任何一个，存储过程都可能在线上突然变慢或返回错数，而且不容易一眼看出来。
