今日关键词空间数据库、GIS、空间索引、R-Tree、融合数据库大家好我是数据库小学妹 做过外卖系统的同学应该都有体会骑手位置、商户坐标、配送范围全是空间数据。存起来容易查起来要命——3公里内的骑手这个查询数据量一大就卡得不行。问题出在哪大概率出在数据库选型上。空间数据不像普通业务数据它有坐标系、有几何运算、有拓扑关系。选错了数据库索引效率差、SQL写不出、性能上不去。目前主流的空间数据存储方案有三个流派PostGIS、MySQL空间扩展、国产融合数据库。今天把它们的核心差异拆开讲清楚。一、先搞懂空间数据长什么样空间数据主要分两类矢量数据用坐标点描述几何形状POINT点一个经纬度坐标比如骑手当前位置LINESTRING线一串坐标点连成的线比如道路、河流POLYGON多边形围成封闭区域比如配送范围、行政区划栅格数据像素网格比如卫星影像、DEM高程数据。这个一般用专门的栅格引擎不在本文讨论范围。空间数据的核心操作空间关系判断A是否在B范围内ST_WithinA和B是否相交ST_Intersects距离计算A到B的直线距离是多少ST_Distance缓冲区分析以某点为中心画3公里圆找出范围内所有目标ST_Buffer空间聚合某区域内有多少个点这些操作的性能取决于数据库的空间索引能力。二、三大方案核心对比2.1 PostGISPostGIS是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年金仓与超图软件达成战略合作空间能力持续增强不足社区生态比PostGIS小复杂GIS分析场景可能需要配合专业GIS软件适合场景信创场景、需要空间数据和业务数据融合分析、不想维护多套系统三、空间索引性能差异的核心空间查询的性能好不好七成取决于索引。3.1 R-Tree索引R-Tree是空间索引的主流算法。它把空间对象用最小外接矩形MBR逐层聚合形成树状结构。PostGIS用GiST索引实现R-TreeMySQL用SPATIAL INDEXKES用空间索引。底层都是R-Tree变种但实现细节和优化程度不同。3.2 索引效率对比实际测试场景1000万个点要素查询某矩形范围内有多少个点方案索引类型查询耗时参考值PostGISGiST50-100msMySQLSPATIAL INDEX100-200msKESGiST、BRIN和SP-GiST三种空间索引80-150ms数据量越大索引效率的差距越明显。百万级以下差别不大千万级以上开始拉开差距。3.3 空间SQL写法对比-- 查找某点3公里范围内的所有商户-- PostGISSELECTname,ST_Distance(geom::geography,ST_SetSRID(ST_MakePoint(116.40,39.90),4326)::geography)ASdistFROMshopsWHEREST_DWithin(geom::geography,ST_SetSRID(ST_MakePoint(116.40,39.90),4326)::geography,3000)ORDERBYdist;-- MySQLSELECTname,ST_Distance_Sphere(location,ST_GeomFromText(POINT(116.40 39.90),4326))ASdistFROMshopsWHEREST_Distance_Sphere(location,ST_GeomFromText(POINT(116.40 39.90),4326))3000ORDERBYdist;-- KESSQL写法与PostGIS类似SELECTname,ST_Distance(geom,ST_SetSRID(ST_MakePoint(116.40,39.90),4326))ASdistFROMshopsWHEREST_DWithin(geom,ST_SetSRID(ST_MakePoint(116.40,39.90),4326),3000)ORDERBYdist;从SQL写法看PostGIS和KES更接近OGC标准MySQL的写法有自己的风格。四、坐标系容易踩的大坑国内空间数据有两个常见坐标系WGS-84GPS原始坐标国际标准GCJ-02国测局坐标高德、腾讯地图用这个BD-09百度坐标在GCJ-02基础上再加偏移不同数据库对坐标系的支持差异PostGIS支持完整的SRID定义和坐标转换PROJ库可以自由转换WGS-84和GCJ-02MySQL的坐标系支持较弱自定义坐标系比较麻烦KES支持坐标系定义和常见转换重点提醒迁移空间数据前先确认源数据的坐标系。不同坐标系混在一起查结果会差几百米到几公里。五、怎么选一张决策表帮你搞定决策维度PostGISMySQLKES融合库空间函数丰富度高800中基础函数中高空间索引性能优秀良好良好坐标系支持完整有限良好业务数据联合查询需跨库同库同库信创合规需评估需评估原生支持运维复杂度中单独维护低低融合架构学习成本中低低社区生态丰富丰富成长中选型建议信创场景或空间业务融合分析选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过滤再做精确计算避免对几何列做函数计算后再过滤会导致索引失效小结空间数据库选型得看具体场景。空间分析是主角还是配角数据量级多大需不需要和业务数据融合查询有没有信创合规要求这几个问题想清楚方案自然就明确了。大家在空间数据存储上踩过哪些坑用的什么方案评论区分享一下 我是数据库小学妹咱们下篇见