企业官网建设流程全解析

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 用 DmJdbcDriver18，JDK 11 及以上用更新的版本。

2.3 Navicat 版本要求：不是所有版本都能连达梦

这里必须说实话：Navicat 早期版本不支持达梦，我印象中 Premium 12 之前是完全没有达梦这个数据库类型的。从 Premium 15 开始官方加入了达梦支持，到 Premium 16 已经比较完善了。如果你用的是很老的版本，直接在新建连接里找不到达梦选项，那不是你的问题，是该升级工具了。

Navicat 有三个产品线：Premium、for MySQL、for DM。如果你本职工作是 MySQL 开发，但项目里突然要接达梦，我的建议是直接用 Premium 版本，一个工具管理所有数据库，不要在多个产品线之间来回切换。至于正版授权方式，官网个人订阅的费用对个人开发者来说还算合理，公司采购走企业授权，这个就不用多说了。

注意：网上有很多"Navicat 永久许可密钥"这类搜索结果，评论区也常有人分享激活工具，这类渠道来源不明，容易踩坑——我并不是建议大家用盗版，而是提醒不要乱装来路不明的包。官方试用版可以先跑 14 天，短期内应付完项目适配绰绰有余。

3. Navicat 连接达梦的完整配置：从新建连接到跑通第一条 SQL

3.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)是所有报错里最有迷惑性的。表面看是认证失败，但实际上有一种情况是：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 的查询构建器辅助生成字典表格

如果你不想手写 SQL，Navicat 的查询构建器也能帮你做大部分工作。在 Navicat 里打开达梦连接，点击"查询" -> "新建查询"，然后切换到查询构建器模式。左侧对象面板勾选你要查询的字段，比如模式、表名、字段名、数据类型这些，它能自动帮你生成对应的 SQL。这个功能对于不熟悉达梦系统视图的同学来说非常友好，相当于帮你把 SQL 给拼好了。

但我个人的建议还是：核心视图的名称最好自己记住，因为这不仅仅是 Navicat 的问题，后续用其他工具（DBeaver、DataGrip 甚至命令行）都要依赖这套视图体系。有了这个基础，数据字典的获取手段就不限于某一个工具了。

4.4 从查询结果到完整文档：导出 Excel 和 Markdown 的实操

查到了元数据之后，怎么变成交付出去的数据字典文档？在 Navicat 里操作路径是这样的：

1. 执行上述查询 SQL，得到结果集。
2. 点击结果集上方的"导出"按钮（在 Navicat 16 里是"导出向导"）。
3. 选择导出格式为 Excel（xlsx），字符集默认 UTF-8 即可。
4. 在字段映射那一步，确认每一列对应得对不对，特别是中文列名，最好把别名改成你自己能看懂的名字。
5. 完成导出后打开 Excel，做一下排版美化，加个筛选功能，数据字典初稿就完成了。

如果想直接生成 Markdown 文档，我建议不要用 Navicat 的导出功能——它默认不支持 Markdown 格式。我的做法是导出一份 CSV 或者 Excel 之后，用 Python 脚本转成 Markdown 表格，顺便自动生成每个表的字段清单。脚本逻辑不复杂，就是读取 Excel 内容，再按表名分组输出：

import pandas as pd df = pd.read_excel("data_dict_raw.xlsx", dtype=str) 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_CONSTRAINTS+ALL_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 的ENGINE=InnoDB这些建表语句后缀，达梦不认，要删掉。
• 注释：MySQL 的字段注释用COMMENT 'xxx'，达梦支持类似的语法，但某些版本在列定义末尾加 COMMENT 会报错，建议建表语句里把注释去掉，建完表再补。

数据量大的表还要考虑分批导出的问题。Navicat 自带的数据传输工具支持按批次插入，但在达梦这种场景下，我更推荐先把表结构通过脚本或 Navicat 结构同步功能建好，再单独导数据，这样出错了容易定位。

5.2 利用 Navicat 的数据传输工具做结构同步

Navicat 的"工具" -> "数据传输"功能支持从 MySQL 直接传到达梦。很多人不知道的是，这个工具不光导数据，还能同步表结构。步骤如下：

1. 在 Navicat 里分别建立 MySQL 连接和达梦连接。
2. 选择"工具" -> "数据传输"。
3. 源选择 MySQL 连接，目标选择达梦连接。
4. 勾选"创建表"选项，并注意在"高级"里取消勾选"包含引擎"之类的 MySQL 专用选项。
5. 先不勾选数据传输，只跑一遍结构同步，确认所有表都能在达梦下建成功。

这一步跑完后，去达梦里检查一下建出来的表：字段名大小写是否正常、自增列是否生效、表注释有没有带过来。有问题的表单独处理，不要试图一键全量搞定，因为总有一些边缘情况会漏。

5.3 类型映射对照表：常见 MySQL 类型到达梦的转换规则

为了少踩坑，我把最常见的 MySQL 类型到达梦的映射规则整理成了表格。这份对照表是我实际迁移项目里反复验证过的：

迁移过程中最容易被忽略的是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_password@localhost:5236 file=/data/backup_backup.dmp log=/data/backup_backup.log

开发环境的数据备份，用 Navicat 的导出功能就够了；生产环境建议走达梦官方的物理备份方案，定时任务 + 异地存储。这个不是 Navicat 的强项，别硬用。

6.4 一个值得留意的性能细节：达梦的执行计划在 Navicat 里怎么看

达梦兼容 Oracle 的 EXPLAIN PLAN 机制。在 Navicat 的查询编辑器里，你写完 SQL 后按快捷键 Ctrl+L（或者点"解释"按钮），就能看到执行计划。注意看几个关键指标：访问方式是全表扫描还是索引扫描、预估行数是多少、有没有走异常的不相关索引。

实战中我发现，从 MySQL 迁过来的表，如果在达梦上没有重建索引，查询性能会非常拉胯。尤其是 MySQL 里习惯用的联合索引、覆盖索引，迁移后要重新审视一遍查询条件，按达梦的优化器习惯设计索引。一个常见问题是迁移后统计信息没更新，导致达梦优化器误判行数。迁移完成后执行一下：

SP_TAB_STAT_INIT('APP_USER', 'T_ORDER');

这是达梦手动收集统计信息的存储过程（库名加用户名和表名），跑完之后执行计划会准很多。这个细节很多从 MySQL 转过来的同学不知道，以为数据导过来就万事大吉了，结果线上跑出来慢得不行，其实往往就是统计信息缺失导致的。

7. 写在最后：把这套流程变成团队的标准化动作

做完整个适配之后，我最大的感触是：Navicat + 达梦这套组合完全够用，但前提是你得把它当作一套严肃的工具链来对待，而不是"连上就行"。数据字典这种基础设施，一定要沉淀成文档和脚本，不要做一次扔一次；迁移的流程要标准化，每一步的验证动作不能因为催得急就跳过；模式权限的管理要有 DBA 配合，开发账号和运维账号分开。

我这边现在已经把数据字典生成脚本放进了项目仓库，每次表结构变更就重跑一遍，字典文档自动更新，评审会上再也不用临时掏手机截图了。如果你正在做类似的国产化数据库适配项目，希望这篇能帮你少走几圈弯路。最后再分享一个小技巧：Navicat 连接达梦之后，在"查询"里可以保存多个常用查询模板，比如查模式列表、查当前用户表清单这类高频操作，存成模板之后团队小伙伴直接用，别让大家重复写系统视图查询 SQL。