今年年中我们在做数据库选型替换,把一批原先跑在 MySQL 上的业务系统平移到国产库,定的目标就是达梦数据库 DM8。开发同事第一反应是:IDE 能不能还用 DataGrip?毕竟 JetBrains 系的操作习惯不是说改就能改的,何况写 SQL、做表结构对比、看执行计划这些活儿,DataGrip 确实顺手。于是我们专门花时间研究了如何在 DataGrip 里连接达梦,包括驱动选择、数据源配置、表结构同步,以及各种让人抓狂的报错。这篇文章就把完整过程整理出来,写给那些希望在 DataGrip 里接达梦、又不想折腾的人。
1. 为什么值得用 DataGrip 连达梦
1.1 达梦的部署形态与兼容模式
达梦数据库在国内政企项目里出现频率很高,尤其在金融、电力、医疗、政务这类需要本地化部署的场景。DM8 的安装方式很多,Windows 上有图形化安装包,Linux 上有命令行安装,也支持国产操作系统环境,比如银河麒麟等;如果只是开发自测,还能用 Docker 快速起一个实例。
达梦有一个比较特殊的地方:初始化实例的时候可以选择兼容模式,常见的是兼容 Oracle 和兼容 MySQL。这个选择会直接影响后续 SQL 写法,比如分页的写法、字符串拼接方式、日期函数调用都会有差异。所以拿到一个达梦环境,第一件事先确认它是按哪种模式初始化的。模式不同,后面 DataGrip 里的准备工作虽然一样,但你在 SQL 编辑器里写出来的业务语法会完全不同。
很多团队之前用的是 MySQL,数据库迁移到达梦之后,开发者不希望连个数据库还要换工具。DataGrip 对数据库类型没有硬性限制,只要数据库提供了 JDBC 驱动,就可以通过自定义驱动的方式接入。这也是 DataGrip 在灵活性上比 Navicat 一类工具更明显的地方。
1.2 DataGrip 连接国产库的实际意义
从实际工作流来看,DataGrip 的价值不只是能敲 SQL。它有智能补全、格式化、执行计划查看、结果集编辑、命令行终端、表结构对比与同步这些功能,整体体验属于第一梯队。如果因为数据库换成了国产库,就得回去用传统管理工具,开发效率大概率会下降。
这里需要坦白说一句:DataGrip 官方并没有把达梦列在默认支持的数据库列表里。你打开 New Data Source,搜 Dameng 是搜不到的。但这不等于不能用,达梦官网提供了标准的 JDBC 驱动,我们只要在 DataGrip 里手动注册一个 Driver,然后像连接 Oracle 一样填连接参数就行。整个过程不需要额外插件,大概十五分钟能搞定。
这里要额外提醒一下:DataGrip 是一款商业软件,官方提供 30 天试用,试用结束以后需要购买订阅。网上有各种“激活码”“破解包”之类的说法,我不建议碰,一是安全性没保障,二是这种工具类软件直接订阅并不贵,甚至如果你的需求只是临时连一下达梦,完全可以用 DBeaver Community 版应急,一样免费。我把 DBeaver 和 Navicat 的连接差异放在文章最后做对比,方便你选型。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 准备工作:拿到正确的达梦 JDBC 驱动
2.1 驱动 jar 从哪里找
连接达梦的第一步,是拿到达梦的 JDBC 驱动 jar。最容易的方式是找一台已经装了达梦的服务器,进入安装目录下的 drivers/jdbc 文件夹,里面通常会有好几个 jar,常见的有 DmJdbcDriver17.jar、DmJdbcDriver18.jar、Dm8JdbcDriver18.jar 等等。如果本机没有安装达梦,也可以去达梦官网的下载页面找到 JDBC 驱动包,解压后同样是这些 jar。
这里要特别注意:不同达梦小版本对应的驱动包可能不一样,驱动和服务端版本不匹配时,连接时会出现各种奇怪的问题,比如握手失败、加密协议不支持等。我踩过的一个坑是拿旧版驱动连新版 DM8 服务端,报错信息非常绕,最后换了达梦安装目录下对应版本的驱动就正常了。所以最稳妥的办法,不是从网上随便找 jar,而是直接从目标服务器安装目录里 copy 一份。
驱动 jar 的来源安全性也要重视。我见过有人从第三方站点下了一个 DmJdbcDriver 的压缩包,解压下来体积不对,明显是被塞了东西。数据库驱动是直接暴露在应用安全边界上的东西,尽量只从达梦官网或官方安装目录获取,别贪方便。
2.2 选择匹配 JDK 版本的驱动
达梦驱动包的命名里有数字,这个数字不是数据库版本,而是对应 JDK 版本要求。比如 DmJdbcDriver18 通常适用于 JDK 1.8 及以上环境,DmJdbcDriver17 适用于 JDK 1.7。DataGrip 本身是跑在较新版本的 JRE 上的,所以按常规情况,直接选择 DmJdbcDriver18 这一类即可。
如果你在 Web 应用里也要用达梦 JDBC,那就需要结合应用服务使用的 JDK 版本来选驱动,比如老系统是 JDK 1.6,那只能选择达梦提供的对应老驱动。不过我们这里只讨论 DataGrip 连接,所以选一个兼容性好的新驱动放在 DataGrip 里就行。
我个人的建议是:连接前先确认服务端达梦的版本号和兼容模式,然后选对应版本自带的 JDBC 驱动;如果 DataGrip 连不上,优先换驱动版本而不是改一堆高级参数。很多时候问题根本不是配置错了,而是驱动和服务端“聊不到一块”。
2.3 把驱动挂到 DataGrip 的 Driver 管理里
DataGrip 里加驱动的入口在 Settings 或 Preferences 下的 Database | Data Sources and Drivers。界面分左右两块,左边是 Data Source 列表,右边是 Drivers 列表。我们需要先注册 Driver,再创建 Data Source。
操作顺序是这样的:在 Drivers 页签点击左上角的加号,Name 填 Dameng,也可以写成 DM8;然后在 Driver Files 区域点击加号,选择 Custom JARs,把刚才准备好的驱动 jar 加进去。添加完以后,Class 区域一般会自动识别出驱动类名,如果没有自动识别,手动输入 dm.jdbc.driver.DmDriver 然后回车确认。
这个 Class 名称是达梦 JDBC 驱动固定的入口类,中间有个小点容易被漏掉:是 dm.jdbc.driver,不是 dm.jdbc。如果你已经加了 jar 但手动填类名时没按回车,DataGrip 不会真的接受这个值,后面测试连接时会一直报“Class not found”,到时候检查这里。
3. 在 DataGrip 里一步步配好达梦数据源:Host、端口、URL 一个都不能错
3.1 新建自定义 Driver 的完整操作路径
在 DataGrip 中真正新建自定义驱动连接,有两条路径。第一条是在 Database 工具窗口上方点击加号,选择 Data Source,再在列表底部找到我们刚加好的 Dameng。第二条是从 Settings 的 Data Sources and Drivers 面板左侧数据源列表里点加号,同样能找到。效果是一样的。
关键是要把驱动注册和建数据源区分开。很多新手会在 Drivers 面板里加完 jar,然后直接在 Data Source 面板里搜 Dameng 搜不到,就开始怀疑人生。其实 Drivers 和 Data Source 是两个独立的列表,必须先把驱动挂在 Drivers 里,之后 Data Source 的驱动下拉框才会出现那个名字。
驱动建好以后,建议在 Data Source 的 General 页签里填连接参数。这个页签的逻辑比较直观,Host、Port、User、Password 四项不说了,Database 这一栏有人会填达梦的数据库名,有人会留空。达梦的逻辑和 MySQL 不太一样,它的“库”概念更弱,更重要的是“模式”即 Schema。所以在 Database 栏里,如果填了内容,通常应该填一个具体的模式名或用户名;如果留空,默认会连接到登录用户对应的默认模式。
3.2 连接参数里容易被忽略的三个细节
第一个细节是端口。达梦的默认端口是 5236,不是 Oracle 的 1521,也不是 MySQL 的 3306。如果服务器上装达梦时没有修改过配置,那 DataGrip 里 Host 填服务器 IP,Port 填 5236 即可。如果达梦管理员改过端口,则需要查安装目录下的 dm.ini 文件里 PORT_NUM 参数,或者问你同事。
第二个细节是 URL 格式。DataGrip 会根据你填的 Host、Port、Database 自动生成 URL,默认长这样:jdbc:dm://127.0.0.1:5236。如果你想在 URL 上追加参数,比如指定模式,可以在 URL 里加 ?schema=xxx,但这个不是必须的,后面在 Schema 页签里勾选更方便。
第三个细节是连接后的 Schema 勾选。点开数据源编辑窗口的 Schemas 页签,你会看到一堆模式名,比如 SYSDBA、SYSAUDITOR 这些。如果业务表建在 SYSDBA 下,就把 SYSDBA 勾上。不要全选,全选会导致元数据加载很慢,尤其是服务器上模式多的时候,DataGrip 可能会卡在 loading 界面很久。
3.3 测试连接的判断思路和成功标志
填完参数后点 Test Connection,DataGrip 会弹连接成功或失败的提示。成功相对简单,左边数据库树会开始加载模式、表、列、索引等信息。第一次连接成功以后,建议先展开一个表看看列和数据类型是否正常显示,再随便写一条 SELECT 1 或者查一张小表验证 SQL 执行没有问题。
如果测试连接失败,不要急着翻日志,先按这个顺序排查:看驱动 jar 是否真的加上了,看 Class 类名是否填写正确,看端口是否可达,看用户名密码是否对。这四个问题覆盖了绝大多数失败场景,我在第 5 章会展开讲各种典型报错。
我在实际项目里配过几十次达梦连接,第一次就成功的概率其实不高,但失败的规律非常强。只要按驱动态、网络态、账号态、模式态四个维度去定位,一般几分钟内能找到原因。
4. 连接成功后:表结构同步与 SQL 操作
4.1 用 DataGrip 的 Schema Diff 同步表结构
很多人关心 DataGrip 如何同步数据库表结构,特别是把 MySQL 业务表迁移到达梦后,需要经常在开发库和测试库之间同步 DDL。DataGrip 内置了 Schema Diff 功能,可以直接对比两个 schema 或两个数据源。
操作方式很直观:在 Database 工具窗口选中要比较的 schema,右键选择 Compare with,再选择目标 schema;或者在一个数据源上右键选择 Compare Schemas,指定另一个数据源里的对象。DataGrip 会打开一个差异面板,左边是 source,右边是 target,中间列出新增表、删除表、字段差异、索引差异。你可以逐条查看 SQL 脚本,勾选需要执行的对象,点 Apply 应用。
实际使用中有一个很重要的提醒:跨数据库类型做结构同步,DataGrip 生成的 DDL 不一定是立即可用的。比如 MySQL 里 datetime 类型到达梦下可能映射成了 TIMESTAMP 或 DATE,这个映射是否合理需要人工判断。再比如 MySQL 的自增列和达梦的 IDENTITY 列,语法差异很大,DataGrip 的同步脚本经常需要手工修正。所以 Schema Diff 适合做“发现差异”和“生成草稿”的用途,真正地执行 DDL 前,最好让熟悉达梦语法的同事过一遍。
4.2 schema 和大小写问题:达梦与 MySQL 最大的不同
达梦在标识符大小写处理上更接近 Oracle:不加双引号的对象名,在库里会统一转成大写;如果你建表时使用了双引号括号起来的“小写表名”,那之后每次操作都必须带双引号,否则就会提示对象不存在。
这个特性在 DataGrip 里非常容易踩坑。用过 MySQL 的人习惯写 select * from user_info,但达梦里如果表是 "user_info" 建的,这样写会直接报“表或视图不存在”。反过来,如果建表时用的是普通写法,那查询时写大写或者小写通常都能识别,因为达梦内部已经统一处理为大写了。
我在 DataGrip 中给团队的建议是:连接达梦后,先写一条查询去 information_schema 类系统视图里看一眼列名的真实存储形式。如果都是大写,那 SQL 规范里就直接约定“所有对象名不要加双引号,统一按大写理解”。这样能规避很大一部分大小写导致的诡异报错。
4.3 日常 SQL 编写与调试功能的实际体验
连接成功后,DataGrip 的代码提示、格式化、执行计划、结果集排序过滤这些能力都还能用。唯一需要注意的是 SQL 方言提示,DataGrip 不认识达梦的方言,所以代码提示可能不完全准确。解决方法是在数据源的 Dialect 设置里,根据达梦初始化时选择的兼容模式,手动选成 Oracle 或 MySQL。这个设置不影响实际连接,但会让 DataGrip 的语法高亮和提示更贴近真实运行环境。
关于达梦的 SQL 写法差异,简单举几个例子。兼容 Oracle 模式下,分页通常会写 SELECT * FROM (SELECT t.*, ROWNUM rn FROM table t WHERE ROWNUM < 20) WHERE rn >= 10;兼容 MySQL 模式下,则可以直接写 LIMIT 10, 10。字符串拼接方面,Oracle 模式常用 ||,MySQL 模式可以用 CONCAT。日期函数也存在类似差异,SYSDATE 在两种模式下都能用,但 NOW() 这种 MySQL 习惯函数就不一定了。
这些差异和 DataGrip 本身关系不大,但因为你选择用 DataGrip 作为主力工具,最好让每个开发都知道当前连的达梦是哪种模式。否则同一条 SQL,小王写得出来,小李写不出来,最后排查了半天发现是模式不同。
5. 高频踩坑记录与解决方案
5.1 驱动类找不到:ClassNotFoundException
现象:Test Connection 时弹 java.lang.ClassNotFoundException: dm.jdbc.driver.DmDriver。
原因:驱动 jar 没有真正加载,或者 Class 名称没填对。这个问题在自定义驱动时出现频率极高。
排查思路:打开 Settings 里的 Drivers 面板,看 Driver Files 区域是否显示 jar 文件名,并且右侧有没有一个绿色的对勾。如果 jar 是灰色的,多半是没生效,可以移除后重新添加,然后重启 DataGrip。再去看 Class 字段,手动输入 dm.jdbc.driver.DmDriver 后一定要按回车,让 DataGrip 确认这个类存在。
5.2 端口不通或连接超时
现象:Test Connection 一直转圈,最后报 SocketTimeoutException、Connection refused 或 Network is unreachable。
原因:达梦服务没启动、端口不对、防火墙拦截、或者服务器上的达梦端口被修改过。
排查思路:先用命令行验证本地能不能连到达梦端口。Windows 上用 telnet ip 5236 或者 netstat -an | findstr 5236,Linux 上用 ss -lnt | grep 5236,看端口是否在监听。然后检查达梦安装目录下的 dm.ini 里 PORT_NUM 参数,确认端口号。最后看防火墙和安全组,确保 5236 或对应端口对外放行。如果是本地开发连远程达梦,还要确认数据库配置了允许远程连接,默认配置下监听地址可能是 127.0.0.1,那就需要改 LISTEN_ADDR 后重启实例。
5.3 连接成功但看不到业务表
现象:连接信息都对,左边数据库树能展开,但列表里看不到业务表,或者只看到一堆系统表。
原因:连接用户的权限不足,或者没有正确勾选 Schema。
排查思路:在数据源编辑窗口的 Schemas 页签里确认业务模式是否被勾选。很多场景下业务数据不在 SYSDBA 下,而是建在某个独立用户下,连接用户需要有对应模式的访问权限。如果换了用户还是看不到,可以去问一下达梦管理员,当前账号是否被授权了业务模式的读取权限。DataGrip 只是把数据库里能看到的元数据展示出来,库层面看不到,工具层面做什么都白搭。
5.4 查询报“列不存在”或“表不存在”
现象:SQL 语句在旧 MySQL 环境里没任何问题,到达梦里执行却报列不存在。
原因:大部分是大小写和双引号问题。
排查思路:确认建表时有没有用双引号。如果用了,查询时必须原样带双引号。如果没查到结果,可以用 DataGrip 左侧表结构里确认实际列名。我在项目里遇到过最典型的场景是,某张表的字段名是 "OrderId",开发同事在代码里写 ORDER_ID,自然查不到。这个不是 DataGrip 的锅,也不是达梦不讲理,而是建表脚本迁移时没有统一大小写规则,后面所有 SQL 都被带偏了。
5.5 达梦新增复合主键的两种方式
场景:业务表原本没有主键,现在想加一个复合主键。
第一种,用 SQL:先确认不需要的主键冲突,然后执行:
sql复制ALTER TABLE schema_name.table_name
ADD CONSTRAINT pk_table_name PRIMARY KEY (col1, col2);
第二种,用 DataGrip 图形操作:右键目标表,选择 Modify Table,在约束或主键区域添加几列,然后保存。DataGrip 会生成对应的 ALTER 语句,当然生成后最好确认一下主键约束名是否规范。
这里有个重要提示:加复合主键之前要先确认列上没有 NULL 值,否则主键约束会创建失败。如果达梦实例是 Oracle 兼容模式,空字符串在某些情况下会和 NULL 混淆,这也是一个容易忽略的坑。
6. 备选工具的差异对比和我现在的组合建议
6.1 DBeaver 连接达梦的差异
DBeaver 社区版是免费开源的,所以很多预算敏感的项目组会选它。连接达梦的思路和 DataGrip 一样:下载达梦 JDBC 驱动,在 DBeaver 的 Driver Manager 里新建驱动,然后把类名和 URL 填上。DBeaver 对达梦的“开箱即用”程度比 DataGrip 更弱一些,虽然新版内置了对部分国产数据库的支持,但实际使用中还是要靠自定义驱动。
差异主要在体验层面:DBeaver 的 SQL 编辑器性能、自动提示、结果集交互不如 DataGrip 顺滑;但 DBeaver 免费这一条,对很多临时场景来说就是最大的优势。如果你只是偶尔查一下达梦的数据,不打算投入太多时间调教工具,DBeaver 值得用;如果你每天都要花大量时间写 SQL、调存储过程、做结构对比,DataGrip 的效率优势更明显。
6.2 Navicat 是否支持达梦
Navicat 在国产数据库支持上也在跟进。比较新的 Navicat Premium 版本里可以直接创建达梦数据库连接,操作方式类似连 MySQL,填 IP、端口、用户名、密码即可。Navicat 的 UI 风格对很多从旧管理工具切换过来的人更友好,表结构设计、数据编辑、导入导出这些功能也比较成熟。
但 Navicat 有一个痛点:它的批量操作和 SQL 编辑体验还是偏“传统软件”风格,对于习惯 JetBrains 系编辑器的人来说,会觉得不够灵活。另外 Navicat 也是商业软件,想省事用免费方案的团队同样会优先考虑 DBeaver。我的看法是,Navicat 适合给运维或者偶尔写点 SQL 的业务人员用,开发主力还是建议留在 DataGrip 或 DBeaver 里选一个。
6.3 我个人的工具组合和一点建议
这套配置我在项目里实际用了两个多月,期间团队从 MySQL 迁移到达梦,日常开发全部基于 DataGrip 完成,没有出现不可绕过的障碍。我个人现在的组合是:开发主力用 DataGrip 连达梦,做结构对比和 SQL 编写;DBeaver 作为备用,偶尔给同事应急用;达梦自带的管理工具保留,用来做数据库层的账号管理、备份和参数调整。
如果你正在做达梦相关的开发,最该记住的三件事是:第一,驱动一定要用对版本;第二,Schema 勾选和大小写规则一定要在项目初期统一;第三,别迷信工智能解决的连接问题,很多坑其实是达梦和 MySQL、Oracle 之间的语义差异导致的。工具只是入口,理解达梦的数据组织方式才是长期不踩坑的关键。
