geo 数据库怎么建才不踩坑？老鸟教你避开那些隐形的大雷

做这行十年了，见过太多老板花大价钱买服务器，结果数据一查，全是垃圾。今天不聊虚的，就聊聊 geo 数据库这摊子事。很多人以为装个 PostGIS 就完事了，其实水深得很。

先说个真事。上周有个做本地生活服务的客户找我，说他们的门店定位总是飘。我一看后台，好家伙，经纬度精度只有两位小数。这就好比你在北京，系统告诉你你在朝阳区，具体在哪？不知道。这种精度，别说做精准营销，连导航都导不准。

这就是第一个坑：精度与存储的平衡。

很多人为了省空间，把坐标存成 float。但在 geo 数据库里，float 的精度有时候会丢失，尤其是在高纬度地区。建议直接用 double 或者专门的地理类型。我测试过，同样的数据量，用 double 比 float 多占一点点空间，但查询准确率提升了 99%。这 1% 的差距，在商业上可能就是几个亿的损失。

再说说索引。

很多新手建完表，直接查。结果呢？几百万条数据，查一次要好几秒。这时候你才想起来加索引。晚了。在 geo 数据库里，索引不是随便加的。B-Tree 索引对范围查询有用，但对空间查询，你得用 GiST 或者 SP-GiST。

我有个朋友，去年搞了个类似美团的项目，初期数据少，没建索引，跑得挺快。后来数据涨到五百万，查询直接卡死。最后不得不全表扫描，服务器 CPU 飙到 100%。这就是典型的“先跑起来再说”的误区。在 geo 数据库领域，前期架构设计不好，后期就是填不完的坑。

还有数据清洗的问题。

你以为数据是干净的？别天真了。来自不同渠道的数据，坐标系可能都不一样。有的用 WGS84，有的用 GCJ02，还有的用 BD09。混在一起查，结果能信吗？我见过最离谱的，把火星坐标当成地球坐标用，结果门店定位到了太平洋里。

所以，在入库前，必须做坐标转换和校验。这一步不能省。虽然麻烦，但能省去后面无数的 debug 时间。

关于性能，再提一点。

很多人喜欢用内存数据库做缓存，比如 Redis。这没错，但要注意，Redis 的空间索引能力有限。对于复杂的空间查询，比如“查找半径 5 公里内所有符合条件的门店”，Redis 可能搞不定，或者性能极差。这时候，还是得靠专业的 geo 数据库，比如 PostGIS 或者 MongoDB 的地理空间索引。

我对比过几个方案。PostGIS 功能最强，支持 SQL 标准，适合复杂查询。MongoDB 开发快，文档型结构灵活，适合互联网快速迭代。如果你做的是传统 GIS 应用，选 PostGIS。如果是互联网产品，数据量大且结构多变，MongoDB 可能更合适。

别听那些卖软件的吹嘘，什么“全能型”，其实都有短板。

最后说说成本。

很多人觉得开源的 geo 数据库免费，就随便用。其实，运维成本很高。PostGIS 需要专业的 DBA 维护，调优参数很复杂。如果你没有技术团队，建议直接上云数据库的服务，比如 AWS 的 Aurora 或者阿里云的 RDS。虽然每年要交钱，但省心。

我算过一笔账。雇一个资深 DBA，年薪至少 30 万。云数据库的年费可能才几万块。这笔账，很多老板算不过来。

总之，建 geo 数据库，别想着一步到位。先跑通核心流程，再优化性能。数据清洗要做细，索引要建对，选型要匹配业务。

如果你还在为定位不准、查询慢发愁，或者不知道该怎么选型，欢迎来聊聊。我不一定能帮你解决所有问题，但至少能帮你避开几个大坑。毕竟，踩坑的钱，比咨询费贵多了。

本文关键词：geo 数据库