PostGIS空间查询语句怎么写?常用函数有哪些?

“我的点为什么查不到？”——PostGIS空间查询的实战避坑指南

你是不是也遇到过这种情况：明明地图上两个要素肉眼可见是相交的，写个ST_Intersects却返回空？或者想查某个缓冲区内的POI，结果把全城数据都拉出来了？别慌，这不是你的SQL写错了，而是你还没搞懂PostGIS空间查询的底层逻辑。我在参与某智慧城市项目时，就曾因坐标系没统一，导致整个路网分析结果偏移了300米——那场面，简直像在玩“大家来找茬”。

空间查询的本质：不是“找”，而是“算”

很多人以为空间查询就是“在地图上圈一块，把里面的要素捞出来”，这其实是误解。PostGIS的空间查询，本质是对几何对象进行数学计算。比如你想查“距离地铁站500米内的便利店”，系统不是真的拿尺子去量，而是用缓冲区算法生成一个圆形多边形，再和便利店的点做空间关系判断。

💡 类比时间：想象你在超市找“保质期还剩3天以上的牛奶”。你不会一瓶瓶看日期，而是让收银系统用“当前日期 - 生产日期 > 3”这个公式批量筛选——空间查询同理，只是公式换成了几何运算。

高频函数实战手册（附真实报错解决方案）

下面这些函数，是我带团队时新人问得最多、也最容易踩坑的。我按使用频率排序，并标注了“死亡陷阱”：

手把手：写一个能跑通的复杂查询

假设你要分析“北京市朝阳区范围内，距离地铁站800米内且评分≥4.5的餐厅”。别被长度吓到，拆解后其实就三步：

-- 步骤1：先确保所有表用同一坐标系（这里用WGS84地理坐标）
UPDATE restaurants SET geom = ST_Transform(geom, 4326) WHERE ST_SRID(geom) != 4326;

-- 步骤2：核心查询（注意geography类型的妙用！）
SELECT 
    r.name,
    r.rating,
    s.station_name,
    ST_Distance(r.geom::geography, s.geom::geography) AS dist_meters -- 强制转为地理类型算真实距离
FROM 
    restaurants r,
    subway_stations s
WHERE 
    r.district = '朝阳区' 
    AND r.rating >= 4.5
    AND ST_DWithin(r.geom::geography, s.geom::geography, 800) -- 800米内
    AND s.city = '北京';

-- 步骤3：创建空间索引加速（生产环境必做！）
CREATE INDEX idx_restaurants_geom ON restaurants USING GIST(geom);
CREATE INDEX idx_subway_stations_geom ON subway_stations USING GIST(geom);

这段代码里最关键的细节：::geography强制转换。因为WGS84的经纬度单位是“度”，直接算距离会出错。转成geography类型后，PostGIS会自动用球面公式计算，结果单位才是米。

性能优化：别让老板等半小时

我见过有人查全国数据不加索引，结果服务器CPU飙到100%持续20分钟。记住这三个黄金法则：

1. 空间索引是生命线：对geometry字段必须建GIST索引，否则每次查询都是全表扫描。
2. 先缩小范围再精细计算：比如先用行政区划裁剪，再做缓冲区分析。就像先筛出“北京的数据”，再算“离地铁站多远”。
3. 慎用ST_Buffer做范围查询：它生成的是多边形，计算开销大。优先用ST_DWithin——它内部做了优化，速度能快10倍以上。

总结：空间查询的“三要三不要”

最后送你我的实战口诀：

• ✅ 要统一坐标系 —— 所有几何体SRID必须一致
• ✅ 要用geography算距离 —— 避免“度”和“米”的混淆
• ✅ 要建空间索引 —— 否则数据量大时你会哭
• ❌ 不要直接比较浮点数 —— 用ST_Equals代替geom1 = geom2
• ❌ 不要在WHERE里用复杂函数 —— 如ST_Buffer(geom, 100)应提前计算
• ❌ 不要忽略NULL值 —— 空几何体会让整个查询崩溃

现在轮到你了！你在写PostGIS空间查询时踩过什么坑？是坐标系问题、性能瓶颈，还是函数用错？**在评论区留下你的“血泪史”**，我会挑三个典型问题详细解答。下期我们讲《PostGIS空间索引原理：为什么你的查询慢得像蜗牛？》