空间数据库选型实战：索引查询性能三维度深度对比

今日关键词：空间数据库、PostGIS、GIS、空间索引、R-Tree、融合数据库

做过外卖系统的同学应该都有体会：骑手位置、商户坐标、配送范围，全是空间数据。存起来容易，查起来要命——"3公里内的骑手"这个查询，数据量一大就卡得不行。

问题出在哪？大概率出在数据库选型上。

空间数据不像普通业务数据，它有坐标系、有几何运算、有拓扑关系。选错了数据库，索引效率差、SQL写不出、性能上不去。

目前主流的空间数据存储方案有三个流派：PostGIS、MySQL空间扩展、国产融合数据库。今天把它们的核心差异拆开讲清楚。

一、先搞懂空间数据长什么样

空间数据主要分两类：

• 矢量数据：用坐标点描述几何形状
• POINT（点）：一个经纬度坐标，比如骑手当前位置
• LINESTRING（线）：一串坐标点连成的线，比如道路、河流
• POLYGON（多边形）：围成封闭区域，比如配送范围、行政区划
• 栅格数据：像素网格，比如卫星影像、DEM高程数据。这个一般用专门的栅格引擎，不在本文讨论范围。

空间数据的核心操作：

• 空间关系判断：A是否在B范围内？（ST_Within），A和B是否相交？（ST_Intersects）
• 距离计算：A到B的直线距离是多少？（ST_Distance）
• 缓冲区分析：以某点为中心画3公里圆，找出范围内所有目标（ST_Buffer）
• 空间聚合：某区域内有多少个点？

这些操作的性能，取决于数据库的空间索引能力。

二、三大方案核心对比

2.1 PostGIS

PostGIS是PostgreSQL的空间扩展插件，是GIS领域的老牌选手。

优势：

• 空间函数丰富，800多个空间函数，覆盖OGC标准
• GiST索引成熟，空间查询性能好
• 支持坐标系转换（PROJ库），全球各种坐标系都能处理
• 社区活跃，文档齐全，遇到问题容易找到解决方案
• 支持栅格数据（PostGIS Raster）

不足：

• 需要单独维护一套PostgreSQL实例
• 空间数据和业务数据分库存储，联合查询要跨库
• 高并发写入场景下性能有瓶颈
• 国产化替代时，需要额外评估合规性

适合场景：GIS专业应用、地理信息系统、需要复杂空间分析的场景

2.2 MySQL空间扩展

MySQL内置了空间数据类型和空间索引，开箱即用。

优势：

• 不需要额外插件，建表时指定空间列就行
• SPATIAL INDEX基于R-Tree，基本的空间查询能用
• 业务数据和空间数据同库，减少架构复杂度
• 运维团队大多熟悉MySQL，学习成本低

不足：

• 空间函数比PostGIS少很多
• 坐标系支持有限，自定义坐标系比较麻烦
• 空间索引在复杂多边形查询下效率一般
• 对三维坐标（Z值）支持不完善
• GIS专业功能不足，不适合重度GIS场景

适合场景：业务系统中附带空间功能（LBS、外卖、打车），空间分析需求不复杂

2.3 国产融合数据库（以KES为例）

国产数据库在空间能力上正在快速追赶。KES V9走的是融合架构路线：把空间能力直接内置到数据库引擎里。

优势：

• 空间数据、关系数据、时序数据在同一个库里
• 一条SQL就能关联空间表和业务表，不用跨库
• 符合信创要求，国产化合规无忧
• 运维一套系统，不用分别维护GIS库和业务库
• 2025年KES与超图软件达成战略合作，空间能力持续增强

不足：

• 社区生态比PostGIS小
• 复杂GIS分析场景可能需要配合专业GIS软件

适合场景：信创场景、需要空间数据和业务数据融合分析、不想维护多套系统

三、空间索引，性能差异的核心

空间查询的性能好不好，七成取决于索引。

3.1 R-Tree索引

R-Tree是空间索引的主流算法。它把空间对象用最小外接矩形（MBR）逐层聚合，形成树状结构。

PostGIS用GiST索引实现R-Tree，MySQL用SPATIAL INDEX，KES用空间索引。底层都是R-Tree变种，但实现细节和优化程度不同。

3.2 索引效率对比

实际测试场景：1000万个点要素，查询"某矩形范围内有多少个点"：

数据量越大，索引效率的差距越明显。百万级以下差别不大，千万级以上开始拉开差距。

3.3 空间SQL写法对比

-- 查找某点3公里范围内的所有商户
-- PostGIS
SELECT name, ST_Distance(geom::geography,
    ST_SetSRID(ST_MakePoint(116.40, 39.90), 4326)::geography) AS dist
FROM shops
WHERE ST_DWithin(geom::geography,
    ST_SetSRID(ST_MakePoint(116.40, 39.90), 4326)::geography, 3000)
ORDER BY dist;

-- MySQL
SELECT name, ST_Distance_Sphere(location,
    ST_GeomFromText('POINT(116.40 39.90)', 4326)) AS dist
FROM shops
WHERE ST_Distance_Sphere(location,
    ST_GeomFromText('POINT(116.40 39.90)', 4326)) <= 3000
ORDER BY dist;

-- KES（SQL写法与PostGIS类似）
SELECT name, ST_Distance(geom, ST_SetSRID(ST_MakePoint(116.40, 39.90), 4326)) AS dist
FROM shops
WHERE ST_DWithin(geom, ST_SetSRID(ST_MakePoint(116.40, 39.90), 4326), 3000)
ORDER BY dist;

从SQL写法看，PostGIS和KES更接近OGC标准，MySQL的写法有自己的风格。

四、坐标系，容易踩的大坑

国内空间数据有两个常见坐标系：

• WGS-84：GPS原始坐标，国际标准
• GCJ-02：国测局坐标，高德、腾讯地图用这个
• BD-09：百度坐标，在GCJ-02基础上再加偏移

不同数据库对坐标系的支持差异：

• PostGIS支持完整的SRID定义和坐标转换（PROJ库），可以自由转换WGS-84和GCJ-02
• MySQL的坐标系支持较弱，自定义坐标系比较麻烦
• KES支持坐标系定义和常见转换

重点提醒：迁移空间数据前，先确认源数据的坐标系。不同坐标系混在一起查，结果会差几百米到几公里。

五、怎么选？一张决策表帮你搞定

选型建议：

• 重度GIS分析：选PostGIS。空间函数全，社区成熟。
• 轻量LBS应用：MySQL够用。空间查询不复杂，业务数据为主，同库维护省心。
• 信创场景或空间+业务融合分析：选KES融合库。空间数据和业务数据在同一个库里，一条SQL关联查询，不用折腾ETL。
• 已有国产数据库规划：直接用KES的空间能力，不额外部署GIS数据库。

六、实战建议

6.1 数据量预估

• 100万条以下：三个方案性能差异不大，按运维便利性选
• 100万-1000万：关注索引类型和查询优化
• 1000万以上：必须做基准测试，索引效率差异明显

6.2 迁移注意事项

• PostGIS到KES：空间函数名称大部分兼容，注意ST_Transform等坐标系函数
• MySQL到KES：空间函数写法差异较大，ST_Distance_Sphere需要改写
• 坐标系迁移：保留原始SRID定义，迁移后验证坐标偏移

6.3 性能优化

• 空间索引一定要建。没有空间索引的空间查询，性能差100倍以上
• 大表空间JOIN，先做空间裁剪（bounding box过滤），再做精确计算
• 避免对几何列做函数计算后再过滤，会导致索引失效

小结

空间数据库选型得看具体场景。空间分析是主角还是配角？数据量级多大？需不需要和业务数据融合查询？有没有信创合规要求？

这几个问题想清楚，方案自然就明确了。

大家在空间数据存储上踩过哪些坑？用的什么方案？欢迎交流分享。