上周客户急得跳脚，盯着屏幕骂娘，说那个GEO数据库不能分析，点查询按钮就是转圈圈，进度条卡在99%半天不动。我一看日志，笑出声，这根本不是数据库崩了，是典型的坐标偏移陷阱。很多做地理围栏、LBS营销的朋友都踩过这个坑，数据看着挺多，一跑批量分析就卡死，或者返回一堆空值，搞得人怀疑人生。

别急着重装环境或者找厂商投诉，先自查三件事。第一步，看坐标精度。很多爬虫抓回来的经纬度，小数点后面只有4-5位，这精度在宏观地图上看着没事，但一进入数据库的索引计算，精度丢失会导致大量点落在边界外，索引树直接爆表。真实案例里，有个做商超周边人流分析的哥们，数据源是某免费地图API，没做重投影，最后GEO数据库不能分析，排查三天发现就是坐标没转对EPSG:4326标准。解决办法简单粗暴，用QGIS批量转一下坐标，或者直接Python脚本预处理，把无效坐标剔干净。这步不做，后面全白搭。

第二步，检查文件编码和分隔符。这是最容易被忽略的“隐形杀手”。CSV文件用UTF-8 BOM编码？还是GBK？如果开头多了个BOM标记，数据库解析第一行字段名时会把\uFEFF当成字段一部分，导致ID列匹配不上。还有，逗号分隔符里如果有个数字带千分位，比如1,000,000，没加引号，数据库会以为这是两个字段。上周我帮一个做物流轨迹分析的朋友解决，就是这问题。他文件里有一列金额，没加双引号，导致整行解析失败，GEO数据库不能分析，其实只因为一个逗号。检查方法：用文本打开前几行，看有没有不可见字符，或者用HexViewer看一眼头部。

第三步，内存和索引类型。别小看这点，批量分析百万级点位，默认索引可能撑不住。我见过不少公司，服务器内存32G，数据10万条就OOM。建议在导入前，根据点位分布密度调整空间索引类型，如果是均匀分布，用Quadtree；如果是城市聚集，用KD-Tree更稳。另外，临时表空间给足，别让Swap把CPU打满。真实价格方面，如果你用自建PostGIS，服务器成本大概在每月800-1500元（32G内存配置），但如果用云厂商的地理服务接口，百万级查询可能要花几十到上百块不等，看并发量。

有个细节坑很多人不知道：数据里如果混入了“null”字符串而不是真正的NULL值，空间函数一调直接报Syntax Error。一定要在ETL阶段把这种脏数据清洗掉，否则GEO数据库不能分析的时候，错误日志只会笼统地说“执行失败”，不会告诉你具体哪行哪列出错。调试的时候，别查全量，切出1000条做子集测试，定位错误行比对着百万行日志找快十倍。

最后说句实话，GEO数据库不能分析，八成不是数据库的锅，是数据源头就不规范。别迷信“开箱即用”，地理数据就是典型的“垃圾进，垃圾出”。你自己动手清洗一遍，虽然费点时间，但能省大钱。别被那些“一键导入”的功能忽悠了，底层逻辑没跑通，再花哨的工具也救不了你。按上面三步查一遍，90%的卡死问题都能解决。如果还不行，再去看连接池超时设置，有时候是网络抖动导致批量请求超时断开，重试机制没加上，整批任务就废了。这套流程我用了五年，稳得很。