地理空间索引需匹配数据类型、索引策略与查询写法：geometry适用于平面坐标系（如UTM），geography适用于球面坐标系（如WGS84）；GIST是默认索引类型，须按字段类型建索引；查询应使用ST_Intersects等可索引函数，并用EXPLAIN ANALYZE验证执行计划。
地理空间索引不是“开了就快”，关键在数据类型、索引策略和查询写法三者匹配。PostGIS 是最常用的开源方案，下面以 PostgreSQL + PostGIS 为例，讲清楚怎么建、怎么查、怎么避坑。
用对数据类型：geometry 还是 geography？
PostGIS 提供两种核心空间类型：geometry（平面坐标系，单位是“坐标单位”，如米或度）和 geography（球面坐标系，单位是米，自动按 WGS84 椭球体计算距离/面积）。
- 做城市内POI检索、园区边界判断——用 geometry，配合 UTM 投影（如 EPSG:32650），索引效率高、计算快；
- 跨省/跨国距离筛选（比如“500公里内机场”）、全球范围统计——用 geography，避免投影变形导致的距离误差；
- 别混用：geometry 列上建了 gist 索引，但用 ST_DWithin(geography, ...) 查询，索引会失效。
建对索引：gist 是默认选择，但要注意字段和顺序
PostGIS 空间索引几乎都用 GIST（Generalized Search Tree）。建索引前确认字段类型和 SRID：
- 对 geometry 列：CREATE INDEX idx_places_geom ON places USING GIST (geom);
- 对 geography 列：CREATE INDEX idx_airports_geog ON airports USING GIST (geog);
- 复合查询常用“空间+属性”组合，例如查“北京市内营业中的商场”：可建联合索引 CREATE INDEX idx_malls_region_status ON malls USING GIST (geom, status)，但注意 GIST 对第二字段的优化有限，更推荐用空间索引 + WHERE 过滤，或结合 B-tree 索引加速 status 字段。
写对查询：让索引真正生效的三个习惯
很多慢查询不是没建索引，而是写法绕过了索引。记住这三点：
- 用 ST_Contains / ST_Intersects / ST_DWithin，别用 ST_Distance < 1000 —— 后者无法走索引，必须全表算距离；
- 查询中涉及坐标转换时（如 ST_Transform），确保转换发生在常量侧，而不是字段侧。错误写法：ST_Intersects(ST_Transform(geom, 4326), ST_GeomFromText(...))；正确写法：先将输入WKT转为目标SRID，再与原字段比较；
- 用 EXPLAIN ANALYZE 看执行计划，确认出现 “Index Scan using xxx” 而非 “Seq Scan”。若出现 Bitmap Heap Scan + Bitmap Index Scan，说明空间索引已参与，属于正常高效路径。
常见卡点与应对
实际部署中容易忽略的细节：
- SRID 不一致：插入数据时没指定 SRID（如 ST_GeomFromText('POINT(116 39)') 缺少 ,4326），后续所有空间函数可能报错或结果异常；
- 索引未自动更新：ALTER TABLE ... ADD COLUMN geom geometry(Geometry, 4326) 后，需手动 UPDATE + CREATE INDEX，不会自动补全；
- 大数据量下 VACUUM 不及时：频繁 UPDATE/DELETE 空间表后，gist 索引膨胀严重，定期运行 VACUUM FULL 或 REINDEX INDEX 可恢复性能。
