PostGIS空间索引怎么建?查询速度如何提?

空间查询慢到怀疑人生？你可能还没建对索引

上周一位读者在后台留言：“Dr. Gis，我用PostGIS查个‘某点周围500米内的餐馆’，结果等了12秒才出结果……是不是数据库坏了？”——其实不是坏了，是缺了“空间索引”这把钥匙。就像去图书馆找书，不靠目录直接翻遍所有书架，能不慢吗？

空间索引是什么？为什么它能提速百倍？

简单说，空间索引就是给地理数据加“目录”。PostGIS默认用的是R-Tree索引（你可以想象成快递柜的分区编号系统：A区放华北包裹，B区放华南包裹）。当你查询“海淀区的咖啡馆”，系统不用扫描全国数据，而是直奔“北京-海淀”这个抽屉。

我在参与某智慧城市项目时，曾处理过300万条POI数据。没建索引前，缓冲区查询平均耗时8.7秒；建完索引后，降到0.03秒——提速近300倍。

三行代码教你建好空间索引

假设你的表叫 restaurants，空间字段是 geom（类型为 geometry(Point, 4326)），只需执行：

CREATE INDEX idx_restaurants_geom ON restaurants USING GIST (geom);
-- 如果是3D或高维数据，推荐用SP-GiST
-- CREATE INDEX idx_restaurants_spgist ON restaurants USING SPGIST (geom);
ANALYZE restaurants; -- 刷新统计信息，让查询优化器更聪明

注意：USING GIST 是关键！这是PostgreSQL的通用搜索树，专为空间数据优化。别写成 BTREE ——那是给数字和文本准备的，对空间数据无效。

索引建了还是慢？三大陷阱你踩了几个？

1. 坐标系不匹配：如果你的geom是WGS84（4326），但查询用了Web墨卡托（3857）的缓冲距离，系统会做动态投影转换——索引直接失效。对策：统一坐标系，或用 ST_Transform 提前转换。
2. 函数包裹了索引字段：比如写 WHERE ST_Buffer(geom, 100) && other_geom，索引就废了。正确写法是 WHERE geom && ST_Expand(other_geom, 100) ——让索引字段“裸奔”在最外层。
3. 小数据量硬上索引：低于1万条记录的表，建索引反而增加维护开销。我建议：数据量 > 5万再考虑空间索引。

进阶技巧：复合索引与部分索引

如果你常查“朝阳区评分>4星的餐厅”，可以建复合索引：

CREATE INDEX idx_restaurants_district_rating 
ON restaurants USING GIST (geom) 
WHERE district = '朝阳区' AND rating >= 4;

这样索引只针对高频子集，体积更小、速度更快。实测在百万级数据中，复合索引比单空间索引再快40%。

终极检验：用EXPLAIN看穿查询计划

执行前加一句 EXPLAIN ANALYZE，看是否出现 Index Scan using ...：

EXPLAIN ANALYZE 
SELECT name FROM restaurants 
WHERE ST_DWithin(geom, ST_SetSRID(ST_MakePoint(116.4, 39.9), 4326), 0.01);

如果看到 Seq Scan（全表扫描），说明索引没生效——回头检查字段名、坐标系、函数写法。

总结：空间索引是性能的“第一颗纽扣”

建索引不是玄学：选对方法（GIST/SPGIST）、避开陷阱（坐标系/函数包裹）、善用复合条件，就能让查询从“分钟级”跃升到“毫秒级”。下期我会讲《如何用BRIN索引处理十亿级轨迹数据》，记得关注。

你在建空间索引时踩过什么坑？或者有什么骚操作提速？评论区留下你的血泪史或神技，点赞最高的送《PostGIS实战手册》电子版！