先说个真实经历。前两年接了一个偏政企方向的项目，数据库必须换到达梦DM8，业务里却有一个躲不掉的位置服务模块——“附近门店”查询。当时第一反应是上网找资料，结果铺天盖地都是MySQL、PostgreSQL做LBS的教程，达梦相关的要么语焉不详，要么直接没人写过。硬着头皮把整套方案在DM8上从零跑通之后，我才意识到，达梦做LBS并没有想象中那么复杂，但它和MySQL的差异足够让一个没经验的人卡上好几天。这篇文章就是把我踩过的坑、最终跑通的方案、以及可以照抄的SQL和Java集成配置全部整理出来，希望后来的人能少走弯路。
先说清楚这篇文章适合谁：被信创或国产化要求推到达梦上、但业务里又绕不开经纬度计算和附近查询的开发者；已经在用达梦、想给现有系统加一个LBS功能的团队；以及正在做MySQL到达梦数据迁移、担心LBS模块会不会“迁过去就废了”的人。文章不吹概念，全程围绕可落地的建表、SQL、优化和集成配置展开。
1. 为什么会有“达梦 + LBS”这个组合：选型与场景拆解
1.1 什么业务会用到达梦上的位置服务
LBS听起来像互联网产品的专属玩法，实际上在政企项目里出现频率一点都不低。我接触过的场景就有：连锁门店管理系统里查“我附近有哪些门店”、外勤巡检App里找“离我最近的巡检点位”、设备管理系统里展示“某个区域内的设备分布”、以及物资调度系统里计算“配送点到用户点的距离”。
这些系统的共同点是：底层数据库往往不是团队能随便选的。监管要求、信创目录、采购清单里写了达梦，那不管之前的原型是用MySQL还是别的什么写的，都得迁过来。位置服务从“技术选型问题”变成了“既定数据库上的实现问题”。
这时候最需要的不是“达梦能不能做LBS”这种空泛讨论，而是一套确切的、能跑通的做法。灵位问题在于，很多团队习惯把位置计算放在MySQL的函数或者应用内存里做，迁到达梦之后，第一反应是“完了，MySQL那套空间函数没了”。其实换一个思路就能顺利落地。
1.2 达梦做LBS的三种路线对比
我在达梦上做过几次调研和实验，也翻过达梦官方文档里关于空间数据的内容，实际可行的路线大概有三条：
| 路线 | 实现方式 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|---|
| A：普通字段 + SQL计算 | 用NUMBER存经纬度，Haversine公式在SQL或应用中算距离 | 迁移成本最低，团队最容易理解，不依赖特殊模块 | 数据量大时性能瓶颈明显，需要自己优化 | 百万级以下点位，团队没有空间数据库经验 |
| B：空间数据模块（DMGEO） | 使用达梦的空间类型和空间索引，类似Oracle Spatial的做法 | 空间能力原生支持，适合复杂几何计算 | 学习成本高，迁移时字段类型、函数都要改，资料少 | 需要多边形、区域判断等复杂空间计算 |
| C：混合方案 | 普通字段存经纬度 + GeoHash分桶粗筛 + Haversine精算 | 性能和易用性平衡，索引可控，迁移改动小 | 需要自己维护GeoHash字段 | 百万到千万级点位，最常见的实战选择 |
我在实际项目中选的是C方案。原因很朴素：团队里不是每个人都会用空间函数，而且自研项目之前的数据模型就是基于经纬度字段设计的，换成空间类型相当于推倒重来。GeoHash只是多一个字符串字段，生成逻辑放在Java里，对现有代码侵入很小，效果却立竿见影。后面所有内容都围绕C方案展开。
2. 环境准备与数据表设计：第一步先把经纬度放对地方
2.1 达梦实例与数据库准备
做LBS之前，先把达梦实例和业务用户准备好。这一步网上教程很多，我只列一个后面所有操作都依赖的最小步骤。
用系统管理员账号（SYSDBA，默认密码通常在安装时设置）登录达梦，执行：
-- 创建独立的表空间，避免和系统表空间混在一起 CREATE TABLESPACE LBS_DATA DATAFILE '/dm8/data/DMSERVER/LBS_DATA.DBF' SIZE 1024 AUTOEXTEND ON NEXT 128 MAXSIZE 8192; -- 创建业务用户并指定默认表空间 CREATE USER LBS_USER IDENTIFIED BY "YourStrongPass123" DEFAULT TABLESPACE LBS_DATA; -- 授予必要的权限 GRANT DBA TO LBS_USER;这里有两个值得注意的点。第一，达梦对标识符默认会转成大写，如果你创建用户的时候写了小写名字，后面用字符串连接时可能会碰到大小写匹配问题。第二，字符集务必在初始化实例时选UTF-8。如果选了GBK，后面代码里传中文参数或者从Navicat里看数据，很容易出现乱码。我在迁移项目里就遇到过查询条件传中文门店名查不到数据的情况，最后排查下来是JDBC连接串里字符集和实例字符集不一致导致的。
2.2 经纬度字段用NUMBER还是空间类型
这是建表前要想清楚的问题。我的结论是：日常LBS场景，用NUMBER(10, 6)就足够了。
原因是经纬度的精度需求。纬度范围-90到90，经度范围-180到180。NUMBER(10, 6)表示整数部分4位、小数部分6位，小数6位对应的精度大约是0.11米左右，对“附近门店”这种场景绰绰有余。而且这个精度下，存储和计算开销都很小。
空间类型和空间索引在某些场景下确实更强，比如判断一个点是否落在某个多边形区域内。但如果只是“算距离+按距离排序”，空间类型反而增加复杂度：字段类型要改，查询函数要换，迁移工具对空间类型的支持也参差不齐。所以非必要不上空间类型，这是我在达梦上实践后的真实体会。
2.3 一张可直接使用的LBS业务表DDL
下面这张表是我在项目里实际用过的结构，包含了后面所有优化需要用到的字段：
CREATE TABLE SHOP ( ID BIGINT IDENTITY(1,1) PRIMARY KEY, SHOP_NAME VARCHAR(128) NOT NULL, CITY_ID INT NOT NULL, LNG NUMBER(10,6) NOT NULL, LAT NUMBER(10,6) NOT NULL, GEO_HASH VARCHAR(12), ADDRESS VARCHAR(256), CREATE_TIME TIMESTAMP DEFAULT SYSTIMESTAMP ); COMMENT ON TABLE SHOP IS '门店位置表'; COMMENT ON COLUMN SHOP.LNG IS '经度，GCJ-02坐标系'; COMMENT ON COLUMN SHOP.LAT IS '纬度，GCJ-02坐标系'; COMMENT ON COLUMN SHOP.GEO_HASH IS 'GeoHash编码，用于粗筛'; CREATE INDEX IDX_SHOP_CITY_GEO ON SHOP(CITY_ID, GEO_HASH); CREATE INDEX IDX_SHOP_LNG_LAT ON SHOP(LNG, LAT);补充一个很容易被忽略的点：COMMENT里我特意写了“GCJ-02坐标系”。因为国内地图服务（高德、腾讯、百度）用的坐标体系和GPS原始坐标不一样。如果你的数据来源是高德坐标，那计算距离时所有点位都用高德坐标，这没问题；但如果一部分数据是GPS坐标，一部分是高德坐标，算出来的距离会偏移几十到几百米，而且很难排查。我一贯的建议是，入库前统一坐标系，并在字段注释里写明，避免后来的人踩坑。
GEO_HASH字段现在可以先留空，后面通过程序回填。IDENTITY(1,1)是达梦里实现自增列的方式，对应MySQL里的AUTO_INCREMENT，这个在迁移章节还会提到。
3. “附近的人”核心SQL：距离计算与四步思维
3.1 为什么要用Haversine而不是别的方式
计算两个经纬度点之间的距离，常见做法有三类：平面近似公式、Haversine公式、Vincenty公式。
平面近似公式把地球当平面，直接用经纬度差算距离。这个公式在几公里范围内误差可以接受，但是纬度越高，经度方向的实际距离越被高估，不推荐作为通用方案。
Vincenty公式精度更高，但计算复杂度也高，像达梦这种数据库里写起来非常繁琐，普通场景没必要。
Haversine公式是球面距离计算的经典方法，精度在几十米量级，SQL写起来也简洁，是业界做LBS最常用的方案。它的核心思路是：通过两点的经纬度差，计算球面上的圆心角，再乘以地球半径得到弧长。公式如下：
a = sin²(Δlat/2) + cos(lat1) * cos(lat2) * sin²(Δlng/2) c = 2 * atan2(√a, √(1−a)) distance = R * c其中R取地球平均半径6371公里。
3.2 Haversine的SQL实现与参数化写法
达梦兼容Oracle语法，所以在写三角函数时要注意函数风格的差异。我一开始尝试在SQL里直接用MySQL风格的RADIANS()函数，结果发现达梦部分版本并不支持这个函数名。为了避免版本差异，我统一用“乘以π再除以180”的方式做弧度转换，这样在任何版本的达梦上都稳。
下面是一个可以直接跑的示例SQL，传入一个目标点（?LNG、?LAT），查询门店表中距离5公里以内的门店，按距离升序排列：
SELECT SHOP_NAME, LNG, LAT, ROUND( 6371 * ACOS( COS(?LAT * 3.14159265358979 / 180) * COS(LAT * 3.14159265358979 / 180) * COS((LNG - ?LNG) * 3.14159265358979 / 180) + SIN(?LAT * 3.14159265358979 / 180) * SIN(LAT * 3.14159265358979 / 180) ), 2 ) AS DISTANCE_KM FROM SHOP WHERE LNG BETWEEN ?LNG - 0.090 AND ?LNG + 0.090 AND LAT BETWEEN ?LAT - 0.090 AND ?LAT + 0.090 HAVING DISTANCE_KM <= 5 ORDER BY DISTANCE_KM;这是一个典型的“先粗筛、再精算”写法：先用经纬度范围把候选集缩小到一个矩形框内，再对框内的点做精确距离计算。WHERE里的±0.090是怎么来的？1个纬度约等于111公里，0.090度约等于10公里；所以这个矩形框大致是一个边长20公里的正方形，把5公里半径的需求先包住。如果查询半径变成10公里，就把0.090改成0.180。
HAVING DISTANCE_KM <= 5这种写法在达梦里是可以用的，但要注意性能不理想时，也可以直接在外层套一层查询。还有一点：如果目标点所在位置特别靠近某个“边界上刚好5公里”、但已经超出矩形框的点，粗筛范围可能把它漏掉。所以粗筛的范围宁可放大一些，比如按目标半径的两倍来做，再用精确距离过滤。
3.3 从“算准”到“算快”：先粗筛再精算
上面那段SQL能跑通，但如果你直接把整个城市几百万个点位都算一遍ACOS，数据库的CPU会很难看。粗筛的价值就在这里：Haversine公式的计算开销很大，而经纬度范围判断走的是普通索引，开销小一个量级。
我把这称为“四步思维”：
- 粗筛：用经纬度矩形框缩小数据范围，走索引。
- 精算：对框内数据用Haversine公式算真实距离。
- 过滤：用真实距离剔除矩形框四个角上“距离其实很远”的点。
- 排序：按距离升序取前N条。
实际使用中，矩形框内往往只有目标点位周围很小一部分数据，精算成本可以忽略不计。这个思路和GeoHash分桶并不冲突，两者可以叠加使用，下一节展开讲。
4. 点位数据量大时的性能优化：GeoHash分桶与索引
4.1 GeoHash原理与达梦实现
当点位数据量到了几十万甚至上百万以后，单纯靠经纬度矩形粗筛仍然可能扫到大量无效数据。这时候GeoHash分桶就派上用场了。
GeoHash的核心思想：把地球按经纬度网格不断二分，每一层格子用一个字符串编码表示，字符串前缀相同的格子在地理上是相邻的。比如wx4g0和wx4g1前缀相同，说明它们在同一片区域附近。这样“查附近”就变成了“查相同前缀的字符串”，能直接走普通索引，比范围扫描更高效。
达梦没有内置GeoHash函数，但这不是问题，因为GeoHash可以在应用层生成。我在Java里维护了一个简单的GeoHash工具，核心思路是：
private static final String BASE32 = "0123456789bcdefghjkmnpqrstuvwxyz"; public static String encode(double lat, double lng, int length) { StringBuilder sb = new StringBuilder(); boolean even = true; int bit = 0; int ch = 0; double latMin = -90, latMax = 90; double lngMin = -180, lngMax = 180; while (sb.length() < length) { if (even) { double mid = (lngMin + lngMax) / 2; if (lng >= mid) { ch = ch * 2 + 1; lngMin = mid; } else { ch = ch * 2; lngMax = mid; } } else { double mid = (latMin + latMax) / 2; if (lat >= mid) { ch = ch * 2 + 1; latMin = mid; } else { ch = ch * 2; latMax = mid; } } even = !even; bit++; if (bit == 5) { sb.append(BASE32.charAt(ch)); bit = 0; ch = 0; } } return sb.toString(); }这个实现足以支撑日常分桶需求。GeoHash编码长度和网格大小的对应关系大致如下：
| GeoHash长度 | 格子宽度（约） | 格子高度（约） | 适合场景 |
|---|---|---|---|
| 4 | 39.1 km | 19.5 km | 城市级粗筛 |
| 5 | 4.9 km | 4.9 km | 几公里级附近查询 |
| 6 | 1.2 km | 0.61 km | 街道级查询 |
| 7 | 152.8 m | 152.8 m | 精确到楼宇附近 |
实际项目中，我通常对全量点位生成6位或7位GeoHash，存入GEO_HASH字段。查询时根据目标点的GeoHash，截取前6位做前缀匹配，就能把候选集锁到几条街道的范围。
4.2 分桶查询的SQL示例
假设目标点（lng=120.15, lat=30.28）在Java里生成的6位GeoHash是wtw3ep，那么查询附近5公里门店的SQL可以写成：
SELECT SHOP_NAME, LNG, LAT, ROUND( 6371 * ACOS( COS(?LAT * 3.14159265358979 / 180) * COS(LAT * 3.14159265358979 / 180) * COS((LNG - ?LNG) * 3.14159265358979 / 180) + SIN(?LAT * 3.14159265358979 / 180) * SIN(LAT * 3.14159265358979 / 180) ), 2 ) AS DISTANCE_KM FROM SHOP WHERE GEO_HASH LIKE 'wtw3ep%' AND LNG BETWEEN ?LNG - 0.090 AND ?LNG + 0.090 AND LAT BETWEEN ?LAT - 0.090 AND ?LAT + 0.090;LIKE 'wtw3ep%'会利用GEO_HASH的普通索引做前缀扫描。加上CITY_ID条件时，走我们建好的组合索引IDX_SHOP_CITY_GEO效果更好。这条查询的执行计划通常第一步就过滤掉了99%以上的无关点位，后面再做的距离计算已经非常轻量。
4.3 组合索引、分区表与执行计划观察
索引设计是LBS性能的关键，这块我吃过亏。一开始我只在LNG和LAT上建了单列索引，发现达梦优化器经常不会同时用两个单列索引，效果很差。改成(CITY_ID, GEO_HASH)组合索引之后，查询响应时间立刻降了一个量级。
如果点位表是按城市或区域维度访问的，强烈建议把CITY_ID放在索引最左侧，这样“查某城市、某片区域”的场景能直接命中索引。如果做全国范围查询，则更推荐给表加分区，比如按CITY_ID做列表分区：
CREATE TABLE SHOP (...) PARTITION BY LIST (CITY_ID) ( PARTITION P_CITY_001 VALUES (1), PARTITION P_CITY_002 VALUES (2), PARTITION P_OTHER VALUES (DEFAULT) );分区表和GeoHash字段配合，查询时达梦会先裁剪到对应分区，再走索引前缀匹配，效果非常显著。观察执行计划可以用达梦的EXPLAIN命令：
EXPLAIN SELECT ... FROM SHOP WHERE GEO_HASH LIKE 'wtw3ep%' AND CITY_ID = 1;重点关注EST_ROWS和OPERATOR列。如果看到CSCN（全表扫描）而不是索引扫描，就要检查是不是条件写法导致索引失效了。常见的失效原因有：对GEO_HASH列加了函数（比如SUBSTR(GEO_HASH,1,6)），优化器就放弃索引了，所以前缀匹配要直接写在LIKE条件里，不要包一层函数。
5. Java集成与迁移踩坑：从MySQL迁到DM8的真实问题
5.1 Spring Boot + MyBatis + Druid 连接达梦的配置
代码层面，最常用的技术栈组合是Spring Boot + MyBatis + Druid连接池。达梦官方提供了JDBC驱动，集成配置跟MySQL不太一样，我给出可直接落地的样例。
首先，把达梦JDBC驱动jar包引入项目。达梦驱动不像MySQL驱动那样发布在中央仓库可以直接下，通常安装目录dmdbms/drivers/jdbc下就有，或者从达梦官网下载。把DmJdbcDriver18.jar放到本地lib目录，然后做本地依赖引入即可。
application.yml里的数据源配置：
spring: datasource: url: jdbc:dm://192.168.1.100:5236/LBS_DATA driver-class-name: dm.jdbc.driver.DmDriver username: LBS_USER password: YourStrongPass123 druid: initial-size: 5 max-active: 20 min-idle: 5 validation-query: SELECT 1注意几个细节：
- 达梦默认端口是5236，不是MySQL的3306。
driver-class-name是dm.jdbc.driver.DmDriver。validation-query用SELECT 1在达梦里可以直接执行，不需要像Oracle那样写SELECT 1 FROM DUAL（达梦也兼容DUAL，写FROM DUAL也行）。- 连接串里的数据库名是服务名而不是库名，这个和MySQL语法不同，我第一次接的时候被坑了一下。
MyBatis里分页是个重点。MySQL里习惯用LIMIT，迁移到达梦后，达梦兼容Oracle的ROWNUM写法。如果你的团队用的是PageHelper分页插件，它会对达梦方言做自动适配；如果是手写分页SQL，建议统一改成ROWNUM风格：
SELECT * FROM ( SELECT T.*, ROWNUM AS RN FROM (SELECT SHOP_NAME, LNG, LAT FROM SHOP WHERE CITY_ID = ? ORDER BY CREATE_TIME DESC) T WHERE ROWNUM <= ? ) WHERE RN > ?;如果你用的是达梦较新版本且开启了MySQL兼容模式，LIMIT也可能直接支持。但从兼容性稳妥的角度，ROWNUM是首选。
5.2 Navicat连接报-2501的处理
热搜词里出现了一个很典型的问题：Navicat连接达梦时提示[hy000] 鐢ㄦ埛鍚嶆垨瀵嗙爜閿欒 (-2501)，这串乱码翻译过来是“用户名或密码错误”。我第一次看到这个报错的时候也愣了一下，因为密码明明是对的。
先说乱码原因：错误信息里的中文是按照GBK编码的，而Navicat客户端用UTF-8解析，所以显示成了乱码。这不是重点，真正要做的是排查为什么“用户名或密码错误”：
- 检查用户名是否包含小写字母。达梦默认会把不带引号的标识符转成大写，所以创建用户时如果写了
LBS_USER，登录时也要传LBS_USER；如果创建时用了小写并加了引号"lbs_user"，那登录时必须精确匹配。 - 检查是否使用了正确的模式。达梦里默认模式名和用户名相同，如果业务表建在别的模式下，Navicat连接后看不到表，容易误以为登录失败。
- 检查5236端口是否通，达梦服务是否启动。
- 检查连接串里的数据库名是否写成了实例名。如果是多实例部署，服务名和实例名的区别会导致认证异常。
我遇到过一个隐蔽情况：安装达梦时设置的SYSDBA密码里有特殊字符，比如@或者#，JDBC连接串里没有做URL编码，导致密码被截断，隐式变成“密码错误”。所以密码里带特殊字符时，建议先在URL里手动编码，或者干脆换一个没有特殊字符的密码。
5.3 迁移过程中的类型映射问题
从MySQL迁移到达梦，除了连接方式，表结构和SQL函数的差异是另一座大山。我把常见的映射关系整理成表：
| MySQL类型 | 达梦类型 | 说明 |
|---|---|---|
| bigint | BIGINT | 直接对应 |
| int | INT | 直接对应 |
| varchar(n) | VARCHAR(n) | 中文场景下注意按字节还是按字符 |
| datetime | TIMESTAMP | 达梦的TIMESTAMP精度更细 |
| text | CLOB | 大文本字段需要改 |
| tinyint(1) | SMALLINT | 布尔语义字段要由程序层处理 |
| decimal | NUMBER | 需要注意精度和小数位数 |
| auto_increment | IDENTITY(1,1) | 自增列定义方式不同 |
| enum / set | VARCHAR + CHECK约束 | 建议直接转VARCHAR，应用层做校验 |
SQL函数差异更是重灾区。IFNULL要改成NVL或COALESCE；NOW()改成SYSDATE；IF()改成CASE WHEN；GROUP_CONCAT改成LISTAGG，而且LISTAGG的语法和MySQL差别不小；字符串拼接从CONCAT(a, b)改成a || b。这些细节不用全部死记，但要意识到“迁移不是导入导出，改SQL是跑不掉的工作量”。
我遇到过最隐蔽的问题是日期格式。MySQL的DATE_FORMAT格式化方式和达梦的TO_CHAR不一样，迁移后报表SQL里的日期条件全部错位，查出来的数据对不上。这种问题靠手工一个个改太痛苦，建议迁移前先做一个SQL函数检查清单，把项目里用到的MySQL函数全部列出来，逐一映射成达梦写法。
6. 实测验证与经验总结
6.1 造数据验证距离准确性
代码和SQL都写好了，最后一步是验证。我建议不要一上来就灌几百万元数据，先用几万条真实坐标验证距离准确性。
我当时用杭州某商圈的两个坐标做测试：一个点纬度30.275，经度120.191；另一个点纬度30.289，经度120.201。用高德地图的测距功能查到的直线距离约1.8公里。跑一遍上面那条SQL，返回结果是1.76公里，误差在可接受范围内。这个测试重点不是精读小数点，而是确认SQL的公式没有写错、坐标系没有混。
验证完准确性，再用一个脚本随机生成几万个点位灌入表里，然后模拟不同查询半径和不同并发量的调用。这时候观察两点：SQL响应时间、数据库CPU占用率。如果数据量到了几十万，且没有走GeoHash分桶，你会发现ACOS函数计算占比极高；加上GEO_HASH LIKE条件后，执行计划里的扫描行数会显著下降。
6.2 性能实测数据参考
在普通虚拟机（4核8G）上，10万条点位数据，未加GeoHash时，一次附近查询的响应时间大约在200~300毫秒；加上城市ID组合索引和GeoHash前缀条件后，降到20~50毫秒。到100万条时，未做优化的查询已经明显扛不住了，可能到秒级；加了分区和分桶后仍然能保持在100毫秒以内。
这个数字只做参考，硬件差一点或好一点都会影响。我想强调的是：点位规模越大，GeoHash的价值越明显，而且它不依赖任何特殊空间模块，普通达梦版本就能跑。
6.3 我走过的弯路与建议
最后分享几个我实际踩过的坑，希望你能避开：
第一，不要在SQL里直接写MySQL专有函数。达梦对Oracle语法兼容很好，但MySQL系函数支持要碰运气。统一用标准函数或手工公式，省去版本烦恼。
第二，GeoHash的精度位数和查询半径要匹配。我之前用5位GeoHash做500米的“附近的人”，结果一个桶覆盖范围太大，过滤效果很差。后来改成按“查询半径/2”来匹配GeoHash位数，效果立刻好了。经验值是：查询半径500米用7位，2公里用6位，5公里用5~6位。
第三，达梦的默认事务隔离级别和MySQL不完全一样，批量更新GEO_HASH字段时要注意提交节奏。我试过一次更新几十万行的GEO_HASH字段，不控制批次，直接把回滚段撑爆了。后来改成每次提交5000~10000行，稳稳跑完。
第四，建索引不是越多越好。(CITY_ID, GEO_HASH)和(LNG, LAT)两套索引在实际场景中保留一个就够。我一开始两套都建，写入时索引维护开销翻倍，查询优化器反而可能选错索引。
根据我的实际经验，达梦上跑LBS比想象中要顺。GeoHash分桶加Haversine精算这套组合，既不依赖特殊模块，又能把查询性能控制在可接受范围，是政企项目里相当稳妥的路线。如果你也刚好被“达梦 + LBS”这个组合困住，照着上面这套方案走，应该能少走好几个晚上的弯路。
