普通join在地理空间数据上不会自动变快，必须满足三个前提：st_intersects等空间谓词须直接写在on条件中、两表几何字段srid必须一致、必须配合&&边界框预过滤；否则即使建了gist索引也无效。
普通 JOIN 在地理空间数据上不会自动变快，必须满足三个硬性前提，否则哪怕建了 GIST 索引也形同虚设。
ST_Intersects 必须直接写在 ON 条件里
优化器只在 JOIN 条件中直接使用空间谓词时才考虑索引扫描。一旦被包裹、变形或挪到 WHERE，就退化成笛卡尔积 + 逐对计算。
- ❌ 错误写法：
SELECT * FROM a, b WHERE ST_Intersects(a.geom, b.geom)—— 先生成全量组合再过滤 - ✅ 正确写法：
SELECT * FROM a JOIN b ON ST_Intersects(a.geom, b.geom)—— 可触发Bitmap Index Scan或Index Scan - ⚠️ 注意：
ST_Within(a.geom, b.geom)、ST_DWithin(a.geom, b.geom, 100)同样适用该规则；但ST_Intersects(ST_Transform(a.geom, 3857), b.geom)会失效——函数干扰导致索引不可用
两个几何字段必须 SRID 一致
PostGIS 在执行空间谓词前会检查 SRID。若不一致，内部会隐式调用 ST_Transform，绕过所有索引。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 用
SELECT ST_SRID(geom) FROM table_name LIMIT 1;确认两边是否相同（如都是4326） - 不一致时，统一转换后重建索引：
ALTER TABLE t ALTER COLUMN geom TYPE geometry(Point, 4326) USING ST_SetSRID(geom, 4326); - ⚠️ 特别注意：
geometry和geography类型不能混用；geography列上的GIST索引对ST_Intersects支持有限，优先转为geometry
必须配合边界框预过滤（&&）压降驱动表规模
即使满足前两条，若驱动表（外层表）太大，仍可能因中间结果膨胀导致内存溢出或超时。加 && 能让 GIST 索引提前剪枝。
- 正确写法：
SELECT a.id, b.name FROM points a JOIN polygons b ON ST_Within(a.geom, b.geom) WHERE a.geom && ST_MakeEnvelope(120.0, 30.0, 121.0, 31.0, 4326); -
&&是 GIST 友好的边界框相交操作，极快；它不保证精确匹配，但能筛掉 90%+ 无关记录 - 如果驱动表是多边形（大表），则应在
b.geom上加&&过滤，而非a.geom
分批更新时务必用 WHERE 约束未处理状态
面对百万级地理关联更新（如 UPDATE ... FROM ... JOIN），单次执行极易失败。分批不是加 LIMIT 就完事，关键在于状态控制。
- 必须在子查询中加入
WHERE alerts.ogc_fid IS NULL，确保每次只处理尚未赋值的记录 - 必须带
ORDER BY（如ORDER BY a.uuid），否则LIMIT/OFFSET在无序结果上会跳行漏数据 - 示例语句：
UPDATE alerts SET ogc_fid = subquery.ogc_fid FROM (SELECT a.uuid, ct.ogc_fid FROM alerts a JOIN competences_territoriales ct ON ST_Intersects(a.location::geometry, ct.wkb_geometry) WHERE ct.competence = 'GN' AND a.ogc_fid IS NULL ORDER BY a.uuid LIMIT 200000) AS subquery WHERE alerts.uuid = subquery.uuid;
真正卡住性能的往往不是函数本身，而是索引没被触发的那几处细节：ON 里少一个括号、WHERE 里多一个转换、SRID 差一个数字、分批时忘了 ORDER BY——这些地方一错，前面所有优化都归零。
