1. 为什么是 Navicat 达梦这次选型的真实背景手里正好有个项目要从 MySQL 迁到国产数据库客户指定了达梦。我第一反应不是去装那个官方的数据库管理工具而是想着能不能继续用 Navicat —— 毕竟团队里从开发到测试大家习惯了 Navicat 的界面和操作逻辑要是换了工具光是培训成本就够喝一壶的了。折腾完一轮之后可以负责任地说Navicat Premium 16 以上版本是真的可以直接连达梦的而且数据字典、查询构建器、导入导出这些核心功能都能正常用不用装额外的插件配置方式也不复杂。这篇文章就把整个过程拆开讲清楚从达梦的版本选择、驱动配置到 Navicat 里的连接参数设置再到数据字典怎么自动生成、MySQL 数据怎么迁移过去最后说说我踩过的几个实在坑。内容面向的是要把达梦纳入日常开发管理体系的团队同学以及接到国产化适配任务、需要快速上手达梦的工程师。我尽量把每一步都写得可以直接照着做包括那些文档里不会告诉你的细节。先说结论达梦不是另一个 MySQL但用 Navicat 管理它体验上可以做到非常接近。关键是前期把环境、驱动和连接方式这三个环节弄对后面就是常规操作了。2. 连接达梦前的准备工作版本、驱动和最容易翻车的细节2.1 达梦数据库的版本选择标准版还是安全版达梦数据库的版本命名看着就头疼什么 DM8、DM8 Security、还有那串很长的版本号带 sec spe 后缀的。我第一次拿到安装包的时候看到文件名是dm8_20230808_rev...这种格式直接愣住了。后来才搞清楚达梦分标准版和安全版功能上差异不大但安全版默认开启了一些安全审计策略如果你只需要做业务开发标准版就够用了。连接达梦之前你得先确认手上数据库实例的版本。可以用命令行工具连进去查也可以直接问 DBA。为什么要确认版本因为不同版本的驱动对连接协议有些微差异用新驱动连老库、用老驱动连新库都有可能报协议错误。我实际遇到的错误是这样的Connection refused (Connection refused)乍一看以为是网络问题结果排查了半天才发现是服务器上跑的是老版本 DM8而驱动用的是新版专用的驱动两边握手失败。提示拿到达梦数据库版本信息最直接的方式是在服务器上执行DMVERSION系统函数或者查V$VERSION视图。没有数据库权限的同学直接问运维要版本号就行这个信息在对接的时候非常重要。2.2 驱动下载与放置DmJdbcDriver 还是 Dm8JdbcDriver达梦官方提供的 JDBC 驱动主要有两个命名版本老的 DmJdbcDriver.jar 和新的 Dm8JdbcDriver.jar。很多人在这一步踩坑因为达梦安装目录下drivers/jdbc文件夹里通常能同时看到多个 jar 包光文件名就够你困惑一阵。Navicat 连接达梦的机制本质上是通过 JDBC 驱动的。你在 Navicat 的新建连接里选择达梦数据库类型它需要指定一个驱动文件。Navicat 默认不携带达梦驱动得手动指定。驱动的版本尽量和数据库服务器版本对应比如服务器是 DM8 就用 Dm8JdbcDriver18.jar。驱动怎么找如果你有达梦的安装介质解压后在安装目录的drivers/jdbc下能找到。如果只有远程数据库没安装包去达梦官网的下载专区找对应版本的驱动也行。DarveDev 版本根据 JDK 版本选择JDK 8 用 DmJdbcDriver18JDK 11 及以上用更新的版本。2.3 Navicat 版本要求不是所有版本都能连达梦这里必须说实话Navicat 早期版本不支持达梦我印象中 Premium 12 之前是完全没有达梦这个数据库类型的。从 Premium 15 开始官方加入了达梦支持到 Premium 16 已经比较完善了。如果你用的是很老的版本直接在新建连接里找不到达梦选项那不是你的问题是该升级工具了。Navicat 有三个产品线Premium、for MySQL、for DM。如果你本职工作是 MySQL 开发但项目里突然要接达梦我的建议是直接用 Premium 版本一个工具管理所有数据库不要在多个产品线之间来回切换。至于正版授权方式官网个人订阅的费用对个人开发者来说还算合理公司采购走企业授权这个就不用多说了。注意网上有很多Navicat 永久许可密钥这类搜索结果评论区也常有人分享激活工具这类渠道来源不明容易踩坑——我并不是建议大家用盗版而是提醒不要乱装来路不明的包。官方试用版可以先跑 14 天短期内应付完项目适配绰绰有余。3. Navicat 连接达梦的完整配置从新建连接到跑通第一条 SQL3.1 新建连接的参数填写细节打开 Navicat Premium点击左上角连接选择达梦数据库。这时候弹窗会让你填主机、端口、用户名、密码。看起来和 MySQL 没区别但有几个细节要注意。主机填达梦服务器 IP如果是本机就是 localhost 或 127.0.0.1。端口达梦默认端口是 5236不是 MySQL 的 3306也不是 PostgreSQL 的 5432。这个坑几乎每个初接触达梦的人都踩过拿 3306 去连达梦报超时是轻的报错信息让人摸不着头脑才是真的烦。用户名达梦的默认用户名是 SYSDBA对应 MySQL 的 root。安装时设置的密码就是 SYSDBA 的密码。驱动点击驱动选项卡选择之前准备好的 DmJdbcDriver18.jar。填完之后可以先点测试连接确认参数没问题再保存。我第一次测试连接时就是漏掉了端口这一步填了默认的 3306怎么看都连不上还以为是防火墙问题折腾半小时。所以说连接参数里端口这个值直接写成 5236别懒。3.2 初次连接常见报错与处理思路连接时最常见的报错我总结成一张表基本覆盖了大家会遇到的情况报错信息真正原因解决方式[HY000] 用户名或密码错误 (-2501)用户名或密码错误或模式不对确认 SYSDBA 密码或用正确的用户名/模式登录Connection refused (Connection refused)端口写错或服务没起来检查达梦服务进程确认端口是 5236No suitable driver found驱动 jar 没加载或版本不匹配重新选择对应版本的 JDBC 驱动Communications link failure网络不通或防火墙拦截检查服务器防火墙放行 5236 端口那个[HY000] 用户名或密码错误 (-2501)是所有报错里最有迷惑性的。表面看是认证失败但实际上有一种情况是Navicat 连接达梦时默认会拿你填的用户名去匹配对应的模式Schema如果你的用户名是 SYSDBA但连接的库模式不是 SYSDBA就会报这个错。解决办法是在连接的高级设置里把模式改成实际使用的模式名或者直接用 SYSDBA 登录后手动切换模式。3.3 跑通后的第一件事确认模式与权限连接成功之后不要急着写 SQL。先看一下左侧树的展开结构达梦的逻辑层级和 MySQL 不一样。MySQL 的层次是服务器 - 数据库 - 表而达梦是服务器 - 用户模式- 表。达梦里一个用户对应一个同名模式模式下面才是表、视图、存储过程这些对象。在 Navicat 里展开达梦连接你会看到用户列表点开一个用户里面才是它的模式对象。如果没有看到预期的表大概率是你的登录用户没有访问目标模式的权限或者是模式选错了。可以用这条 SQL 快速确认当前会话所在的模式SELECT SYS_CONTEXT(USERENV, CURRENT_SCHEMA) FROM DUAL;达梦兼容 Oracle 的 DUAL 虚表这行语句在达梦里完全能跑通。如果你的实际模式不是预期的那个执行ALTER SESSION SET CURRENT_SCHEMA 目标模式名;切换或者让 DBA 给你授予对应权限。4. 数据字典从手工整理到自动生成的全流程4.1 为什么需要数据字典它到底解决什么问题数据字典是这篇的重头戏。做过数据迁移或者跨系统对接的同学都有这种体会没有数据字典你面对几十张表只能一个一个猜。字段是干嘛的哪个表是主表那个CREATED_TIME是业务时间还是系统时间没有一份结构化的数据字典文档这些问题在评审会上能来回拉扯好几轮。数据字典本质上就是把数据库的元数据表结构、字段含义、约束、索引、注释整理成一份可阅读、可检索的文档。达梦数据库本身存了这些元数据但你能不能高效地把它们提取出来变成一份漂亮的文档就是工具链的问题了。用 Navicat 做数据字典核心思路是达梦的系统视图 Navicat 的导出功能组合。系统视图负责把结构信息查出来导出功能负责把这些查询结果变成 Excel 或 Markdown。掌握了这个思路以后换任何数据库都能自己建立一套字典生成流程。4.2 达梦的元数据视图查询表、字段、注释的核心 SQL达梦和 Oracle 同源系统视图的命名习惯也类似。下面这几条 SQL 是我实际在用的可以覆盖大部分数据字典需求。查所有表SELECT OWNER AS 模式, TABLE_NAME AS 表名, COMMENTS AS 表注释 FROM ALL_TAB_COMMENTS WHERE TABLE_TYPE TABLE ORDER BY OWNER, TABLE_NAME;查某张表的字段信息SELECT C.OWNER AS 模式, C.TABLE_NAME AS 表名, C.COLUMN_NAME AS 字段名, C.DATA_TYPE AS 数据类型, C.DATA_LENGTH AS 数据长度, C.NULLABLE AS 是否为空, C.COMMENTS AS 字段注释 FROM ALL_COL_COMMENTS C WHERE C.TABLE_NAME 你的表名 ORDER BY C.COLUMN_ID;注意达梦的大小写处理逻辑如果建表时字段名是大写的查询时也要用大写否则可能查不到结果。这个问题在导数据字典时很常见我一开始用 Navicat 的图形界面生成报表发现注释列总是空的后来排查发现就是大小写对不上的问题。还有一点ALL_TAB_COMMENTS和ALL_COL_COMMENTS只能用来看你有权限访问的对象。如果某个模式你只有表的 SELECT 权限但没有视图权限查出来的字典会缺东西。做全库字典前最好用 SYSDBA 或具有 DBA 角色的账号登录。4.3 用 Navicat 的查询构建器辅助生成字典表格如果你不想手写 SQLNavicat 的查询构建器也能帮你做大部分工作。在 Navicat 里打开达梦连接点击查询 - 新建查询然后切换到查询构建器模式。左侧对象面板勾选你要查询的字段比如模式、表名、字段名、数据类型这些它能自动帮你生成对应的 SQL。这个功能对于不熟悉达梦系统视图的同学来说非常友好相当于帮你把 SQL 给拼好了。但我个人的建议还是核心视图的名称最好自己记住因为这不仅仅是 Navicat 的问题后续用其他工具DBeaver、DataGrip 甚至命令行都要依赖这套视图体系。有了这个基础数据字典的获取手段就不限于某一个工具了。4.4 从查询结果到完整文档导出 Excel 和 Markdown 的实操查到了元数据之后怎么变成交付出去的数据字典文档在 Navicat 里操作路径是这样的执行上述查询 SQL得到结果集。点击结果集上方的导出按钮在 Navicat 16 里是导出向导。选择导出格式为 Excelxlsx字符集默认 UTF-8 即可。在字段映射那一步确认每一列对应得对不对特别是中文列名最好把别名改成你自己能看懂的名字。完成导出后打开 Excel做一下排版美化加个筛选功能数据字典初稿就完成了。如果想直接生成 Markdown 文档我建议不要用 Navicat 的导出功能——它默认不支持 Markdown 格式。我的做法是导出一份 CSV 或者 Excel 之后用 Python 脚本转成 Markdown 表格顺便自动生成每个表的字段清单。脚本逻辑不复杂就是读取 Excel 内容再按表名分组输出import pandas as pd df pd.read_excel(data_dict_raw.xlsx, dtypestr) for table, group in df.groupby(表名): print(f### {table}) print(| 字段名 | 类型 | 长度 | 允许空 | 注释 |) print(|-------|------|------|-------|------|) for _, row in group.iterrows(): print(f| {row[字段名]} | {row[数据类型]} | {row[数据长度]} | {row[是否为空]} | {row[字段注释]} |)这样出来的 Markdown 文件结构非常清晰直接放到项目的 docs 目录里或者发布到内部知识库都可以。整个过程手工操作十分钟以内以后数据库表结构变了把脚本重跑一遍就能同步更新字典不用每次手写文档。提示很多团队对数据字典的需求不仅仅是表字段还包括索引、主外键关系。建议把以下几条 SQL 也跑出来一并合并进文档主键信息可以查ALL_CONSTRAINTSALL_CONS_COLUMNS索引信息查ALL_INDEXES和ALL_IND_COLUMNS。表格层面用 Navicat 的导出功能多导几次然后合并就行。5. 数据库迁移实战MySQL 到达梦的数据搬家与类型映射5.1 迁移前的检查清单版本、字符集、特殊字段做数据迁移最忌讳的是上来就直接导数据。达梦和 MySQL 虽然都是关系型数据库但细节差异不少提前规划能少走很多弯路。我列的检查清单是这样版本检查源 MySQL 的版本主要影响导出的 SQL 语法兼容性、目标达梦的版本影响驱动的选择。字符集MySQL 用的 utf8mb4达梦对应的是 UTF-8。理论上都是 UTF但实际迁移中如果两端字符集不一致中文会变成乱码。自增列MySQL 的AUTO_INCREMENT到达梦要改成IDENTITY自增列。存储引擎相关MySQL 的ENGINEInnoDB这些建表语句后缀达梦不认要删掉。注释MySQL 的字段注释用COMMENT xxx达梦支持类似的语法但某些版本在列定义末尾加 COMMENT 会报错建议建表语句里把注释去掉建完表再补。数据量大的表还要考虑分批导出的问题。Navicat 自带的数据传输工具支持按批次插入但在达梦这种场景下我更推荐先把表结构通过脚本或 Navicat 结构同步功能建好再单独导数据这样出错了容易定位。5.2 利用 Navicat 的数据传输工具做结构同步Navicat 的工具 - 数据传输功能支持从 MySQL 直接传到达梦。很多人不知道的是这个工具不光导数据还能同步表结构。步骤如下在 Navicat 里分别建立 MySQL 连接和达梦连接。选择工具 - 数据传输。源选择 MySQL 连接目标选择达梦连接。勾选创建表选项并注意在高级里取消勾选包含引擎之类的 MySQL 专用选项。先不勾选数据传输只跑一遍结构同步确认所有表都能在达梦下建成功。这一步跑完后去达梦里检查一下建出来的表字段名大小写是否正常、自增列是否生效、表注释有没有带过来。有问题的表单独处理不要试图一键全量搞定因为总有一些边缘情况会漏。5.3 类型映射对照表常见 MySQL 类型到达梦的转换规则为了少踩坑我把最常见的 MySQL 类型到达梦的映射规则整理成了表格。这份对照表是我实际迁移项目里反复验证过的MySQL 类型达梦类型注意事项INT / INTEGERINT直接对应BIGINTBIGINT直接对应VARCHAR(n)VARCHAR(n)长度按字符算MySQL 也按字符基本没问题TEXTCLOBTEXT 需要转成 CLOB否则达梦不认DATETIMETIMESTAMP直接对应TIMESTAMPTIMESTAMP直接对应DECIMAL(m,n)DECIMAL(m,n)直接对应BLOBBLOB直接对应TINYINTSMALLINT / TINYINT达梦有 TINYINT 类型根据值范围选择合适的ENUMVARCHARENUM 在达梦里没有转成 VARCHAR 加 CHECK 约束更稳妥迁移过程中最容易被忽略的是TEXT到CLOB的转换。如果你直接用原生 SQL 导数据没改类型的话SQL 执行会直接报错说你使用了不支持的数据类型。用 Navicat 数据传输工具的话它在内部会做一部分自动映射但保险起见我还是建议先结构同步一遍再对照上面这个表检查一遍。5.4 迁移后的验证数据一致性、自增重置和常用 SQL 回归数据导完后别急着宣布完成。三件验证工作必须做数据量核对每张表源库和目标库的 COUNT(*) 是否一致。注意大表 count 很慢但这一步不能省。抽样数据检查不要只看数量要抽几行关键数据对比内容有没有出现乱码、小数位丢失、时间格式错乱。业务 SQL 回归把项目里常用的查询拿出来在达梦上跑一遍重点看分页语法、日期函数、字符串拼接这些差异重灾区。这里插一句达梦对分页的处理和 MySQL 不一样。MySQL 是LIMIT offset, count达梦兼容 Oracle 风格更推荐ROWNUM或者FETCH FIRST N ROWS ONLY。如果你项目里 SQL 是直接拼的迁移后这些查询大概率要改一版。6. 日常管理中的高价值技巧模式、权限和运维细节6.1 模式和用户的关系理解达梦的权限模型达梦的权限模型一句话概括用户名即模式名用户拥有的对象放在同名模式下。你在 Navicat 里能看到用户列表展开某个用户里面的表其实是这个用户模式下的表。而在 MySQL 里数据库和用户是两个完全独立的概念这点思维转换非常重要。日常开发中如果要新建一个业务账号DBA 一般会这样做-- 创建用户并指定密码 CREATE USER APP_USER IDENTIFIED BY your_password; -- 授予基础权限 GRANT CREATE SESSION TO APP_USER; GRANT SELECT, INSERT, UPDATE, DELETE ON APP_USER.T_ORDER TO APP_USER;注意达梦的双引号内密码区分大小写如果密码里有特殊字符双引号包裹能避免很多问题。用 Navicat 连接达梦时填的账号名就是用户名连接成功后左侧默认展示的就是这个账号同名模式下的对象。如果你有 DBA 权限可以切换到其他模式看数据不需要重新连接。6.2 用 Navicat 的模型功能绘制 ER 图快速理解存量数据库结构接了不熟悉的存量达梦库最头疼的是没人能讲清楚表关系。Navicat 的模型功能在这种情况下非常好用。右键点击达梦连接选择打开模型它会让你勾选要加载的表选完后自动生成 ER 图主外键关系用连线标出来。这个功能对于理解达梦模式间的关联比数据字典更直观。我在做数据迁移前的表结构分析时就是靠这个把 40 多张表的关系梳理清楚的。不过有一点要注意如果表本身没有定义外键约束Navicat 模型里也不会有连线这种场景下还是要回到数据字典的备注里找线索。6.3 日常运维的备份思路什么时候该用逻辑备份什么时候用物理备份达梦的备份和 MySQL 不太一样。MySQL 生态大家习惯了用 mysqldump、binlog而达梦的备份体系更接近 Oracle物理备份用 RMAN 类似工具逻辑备份用 DMP 导出。在 Navicat 里你可以直接选中模式右键备份向导做逻辑导出。也可以执行达梦的 dexp 命令行工具导出为 dmp 文件dexp SYSDBA/your_passwordlocalhost:5236 file/data/backup_backup.dmp log/data/backup_backup.log开发环境的数据备份用 Navicat 的导出功能就够了生产环境建议走达梦官方的物理备份方案定时任务 异地存储。这个不是 Navicat 的强项别硬用。6.4 一个值得留意的性能细节达梦的执行计划在 Navicat 里怎么看达梦兼容 Oracle 的 EXPLAIN PLAN 机制。在 Navicat 的查询编辑器里你写完 SQL 后按快捷键 CtrlL或者点解释按钮就能看到执行计划。注意看几个关键指标访问方式是全表扫描还是索引扫描、预估行数是多少、有没有走异常的不相关索引。实战中我发现从 MySQL 迁过来的表如果在达梦上没有重建索引查询性能会非常拉胯。尤其是 MySQL 里习惯用的联合索引、覆盖索引迁移后要重新审视一遍查询条件按达梦的优化器习惯设计索引。一个常见问题是迁移后统计信息没更新导致达梦优化器误判行数。迁移完成后执行一下SP_TAB_STAT_INIT(APP_USER, T_ORDER);这是达梦手动收集统计信息的存储过程库名加用户名和表名跑完之后执行计划会准很多。这个细节很多从 MySQL 转过来的同学不知道以为数据导过来就万事大吉了结果线上跑出来慢得不行其实往往就是统计信息缺失导致的。7. 写在最后把这套流程变成团队的标准化动作做完整个适配之后我最大的感触是Navicat 达梦这套组合完全够用但前提是你得把它当作一套严肃的工具链来对待而不是连上就行。数据字典这种基础设施一定要沉淀成文档和脚本不要做一次扔一次迁移的流程要标准化每一步的验证动作不能因为催得急就跳过模式权限的管理要有 DBA 配合开发账号和运维账号分开。我这边现在已经把数据字典生成脚本放进了项目仓库每次表结构变更就重跑一遍字典文档自动更新评审会上再也不用临时掏手机截图了。如果你正在做类似的国产化数据库适配项目希望这篇能帮你少走几圈弯路。最后再分享一个小技巧Navicat 连接达梦之后在查询里可以保存多个常用查询模板比如查模式列表、查当前用户表清单这类高频操作存成模板之后团队小伙伴直接用别让大家重复写系统视图查询 SQL。