DataGrip连接达梦数据库完整指南：从JDBC驱动到排障实战

最近接手一个从Oracle往达梦数据库迁移的项目，数据切过去了，开发工具却卡了我整整两天。打开DataGrip一看，驱动列表里根本没达梦这一项。网上翻了很多资料，一半是讲达梦自带的DM管理工具怎么用，另一半是零散提问没人完整回答。后来我自己把驱动、连接、日常排障整个捋了一遍，总算搞顺了。这篇就专门写DataGrip连接达梦数据库的完整过程，从JDBC驱动怎么选、DataGrip驱动管理器怎么配，到连接成功后的锁表排查、乱码处理、权限问题，全是我实际踩过的坑，希望能让你少走几小时弯路。

1. 为什么DataGrip默认连不上达梦：JDBC驱动的"缺席"问题

先说结论：不是DataGrip不行，是JetBrains没把达梦驱动内置进去。

DataGrip连接数据库靠的是JDBC驱动，这套机制本身支持任何实现了JDBC规范的数据库。但DataGrip内置的驱动列表，覆盖的是PostgreSQL、MySQL、Oracle、SQL Server、SQLite这些主流数据库。达梦是达梦数据库股份有限公司的商业闭源产品，JDBC驱动JAR包是有许可协议的，由官方提供分发，JetBrains不可能未经过授权就把它打包进IDE。所以DataGrip不认达梦，跟"达梦不好连"是两码事，只是缺一个手动注册驱动的步骤。

理解了这层逻辑你就知道，网上看到"DataGrip破解版"跟连接达梦没有任何关系，那纯粹是许可证层面的另一个话题。连接达梦的本质，就是把达梦官方驱动JAR塞进DataGrip，让IDE知道"哦这又是一种数据库"。

另外一个容易被忽略的点是DataGrip版本。我实测下来，2020版本以上的DataGrip对自定义驱动的支持要好很多，主要体现在Schema自动解析、代码补全、连接测试的报错信息这几个方面。版本太老的话，即使驱动注册成功，连接后也可能出现表结构不刷新、编辑器卡顿的问题。如果你还在用2019或者更早的版本，建议先升级。

还有一点值得提前说：达梦数据库在初始化实例的时候可以选择兼容Oracle语法还是MySQL语法，绝大多数生产环境选的是Oracle兼容模式。这个选择会影响你在DataGrip里用的Dialect（方言）配置，后面会专门讲。

2. 先备好驱动：达梦JDBC驱动的版本选择和获取路径

连接达梦之前，第一件事是把JDBC驱动JAR搞到手。这里面的版本门道比想象中多。

2.1 驱动的两种获取方式

第一种，在安装了达梦数据库的服务器上直接找。达梦安装完成后，JDBC驱动放在安装目录的drivers/jdbc子目录下，比如DM8默认安装路径：

/dmdbms/drivers/jdbc/DmJdbcDriver18.jar

这个JAR文件可以直接从服务器拷贝到本机，不需要额外联网下载，最稳妥。

第二种，从达梦官网的技术支持/下载中心获取。独立发布的JDBC驱动包里面一般包含多个版本的JAR，按数据库版本和JDK版本区分。

2.2 版本匹配关系，别拿老驱动配新库

达梦数据库目前的常见版本是DM7和DM8，两者的JDBC驱动不能混用。我见过有人在DM8的库上用了DM7的驱动，连接时报了一堆无法解析的类错误。大致对应关系如下：

这里有个细节很多人踩过：驱动类名新旧版本不一样。DM8新驱动建议写dm.jdbc.driver.DmDriver，旧版写dm.jdbc.driver.DmJdbcDriver。如果DataGrip提示"Driver class not found"，八成是类名填错了。

选驱动还有一个隐藏坑：JDK版本。DmJdbcDriver18.jar名字里的18指的是JDK 1.8，不是达梦版本号。如果你本机的DataGrip用的是JDK 11或者17，老驱动JAR在类加载阶段可能直接报UnsupportedClassVersionError，这个错误一出现，基本就是驱动JAR编译版本太老。解决办法就是换新驱动JAR，或者给DataGrip指定一个JDK 1.8的运行时。

2.3 驱动JAR的存放位置

DataGrip添加自定义驱动时，可以直接指定本机任意路径下的JAR文件，不需要放到DataGrip安装目录里。但我建议单独建一个目录管理这些第三方驱动，比如：

D:\drivers\dm\DmJdbcDriver18.jar

为什么这么做？因为DataGrip在自定义驱动配置里引用的是绝对路径，如果你后面升级DataGrip或者换了电脑，驱动路径乱了会导致连接失败。统一管理JAR文件，迁移环境时把驱动目录一起挪走就行，不会丢。

3. DataGrip驱动管理器配置：字段逐项讲解

驱动JAR拿到手，接下来就是在DataGrip里注册。这一步操作不难，但每个字段的含义得搞明白，不然填错一个就白折腾。

3.1 打开驱动管理器的入口

在DataGrip里有好几个入口能到驱动管理器：

• 左侧数据库面板右上角的工具图标（扳手图标）
• File → Data Sources and Drivers
• Settings → Database → Data Sources and Drivers

进入后能看到两个标签页：Data Sources和Drivers。别在Data Sources里直接点"+"选数据库，那样选不到达梦。要在Drivers标签页里先新建一个驱动，再去Data Sources里创建数据源。

3.2 新建驱动并填写关键字段

在Drivers标签页点左上角的"+"，新建一个驱动。名称我建议填DM8，简单直白。最重要的是下面几个字段：

Class字段：填dm.jdbc.driver.DmDriver。这个就是驱动的主类，DataGrip靠它才知道用哪个类去和数据库建立连接。如果填错，连接时会报"Could not find class"。

添加入口：点击"+"添加JAR文件，把DmJdbcDriver18.jar选进来。添加成功后，下面会显示JAR的路径。

URL模板：填写jdbc:dm://{host}:{port}。注意后面不要跟数据库名，达梦的JDBC URL习惯是jdbc:dm://主机:端口，库的选择是靠登录用户的Schema来定位的。这一点跟MySQL的写法不一样，我见过有人顺手写成jdbc:dm://host:port/dbname，结果怎么都连不上。

Dialect（方言）：下拉框里选一个合适的方言。达梦兼容Oracle语法的话，可以选Oracle。DataGrip会用它来生成SQL提示和代码补全。选错了不影响连接，但会影响到写SQL时的智能提示，比如用||拼接字符串的语法在Oracle方言下才能正常提示。

3.3 驱动注册后，在Data Sources创建连接

驱动配置完，切到Data Sources标签页，点"+"，这次在驱动列表里就能看到刚才新建的DM8了。选中后填写连接信息：

• Host：达梦数据库服务器IP
• Port：端口，默认是5236
• User：登录用户名，比如SYSDBA
• Password：对应的密码

填完先点Test Connection，能通过说明驱动和连接参数没问题。这时候有一件事特别容易被忽略：DataGrip可能要求你下载某个没有的驱动文件，但实际上我们用的是供应商自带的JAR，找到后直接选择即可。

这里再补充一句，很多教程会让你在Settings → Plugins里装第三方达梦插件，实测没必要，手动注册驱动是所有方案里最干净、最可控的。当然，如果你装完插件后能正常工作，也不冲突，但驱动JAR的版本匹配问题插件解决不了，该手动配还得手动配。

4. 建立连接时最容易踩的四个坑：URL、Schema、权限、超时

驱动注册好了，连接参数填对了，但测试连接还是报错？别急，这四类问题基本覆盖了所有情况。

4.1 端口和网络：连接超时，先别怀疑配置

初次连接达梦，最常见的报错是connect timed out。这时候90%的概率不是DataGrip配置问题，而是网络根本到不了数据库服务器。排查顺序如下：

1. 先ping一下数据库服务器IP，确认网络通不通
2. 再用telnet或者nc测一下5236端口，telnet 192.168.1.100 5236，端口不通就说明防火墙拦了
3. 达梦数据库服务默认监听端口是5236，但运维出于安全考虑可能改成其他端口，需要找DBA确认实际端口

还有一种容易被忽略的情况：达梦服务端配置了仅监听localhost。这种情况下，即使服务器本地能连，其他机器也连不上。这通常是达梦实例初始化时的配置决定，需要DBA去改dm.ini里的监听地址配置并重启服务。

4.2 URL不带数据库名，Schema才是核心

我刚开始用DataGrip连达梦时，一直在URL里纠结要不要加上库名或实例名。后来确认了：达梦的JDBC URL格式就是jdbc:dm://host:port，不需要指定数据库名。你把库信息写上去反而可能触发驱动解析错误。

达梦的逻辑是：登录用户的Schema决定你默认看到哪个库。比如用SYSDBA登录，默认就在SYSDBA这个Schema下。想访问其他用户建的表，有两种办法：

• 写SQL时用模式名.表名，比如SELECT * FROM HR_TEST.EMPLOYEE
• 在DataGrip的Console里执行SET SCHEMA 模式名，把当前会话的Schema切过去

这跟Oracle的使用习惯几乎一样，达梦在Oracle兼容模式下就是这样的行为。

4.3 权限不够：表或视图不存在

很多时候连接能成功，但展开Schema列表一看，别人的库表全都不见。这不是DataGrip的Bug，是权限问题。

达梦的用户权限体系跟Oracle类似，普通用户默认只能看到自己有权限的对象。如果你拿一个只读账号连达梦，看不到别的Schema的表很正常。碰到这种情况，要么找DBA授权，要么用更高权限的账号。我自己的习惯是，开发环境直接配一个对目标Schema有读取权限的专用账号，生产环境则坚持最小权限原则。

另外，DataGrip首次刷新Schema元数据时，如果库表特别多，会明显卡在"Loading"状态。这是元数据抓取的开销，不用担心，刷新完一次就会缓存下来。如果实在卡太久，可以在数据源属性的Schemas标签页里只勾选需要的Schema，减少抓取范围。

4.4 登录失败：账号、密码、加密规则

报invalid username or password，说明网络和驱动都通了，只是认证没过。除了常规的账号密码检查，还要注意达梦的密码策略。很多达梦环境初始化后，SYSDBA默认密码是SYSDBA或安装时设置的密码，但如果系统管理员做过安全加固，密码策略可能要求定期更换，原密码已经失效。

还有一点：达梦连接参数支持SSL和加密认证，如果服务端开了更强的认证要求，普通JDBC客户端可能连不上。遇到这种情况，先用DM管理工具在服务器本地登录一遍，确认账号密码没问题；如果DM管理工具能连而DataGrip连不上，再检查是不是连接参数少了加密配置。

我把这几个坑汇总成下面这个排查表格：

5. 连接成功只是开始：表锁排查、乱码与日常操作

DataGrip能正常查询达梦库的数据后，你以为就万事大吉了？实战里还有几个问题几乎每个人都会遇到，提前了解能省不少事。

5.1 表被锁住了怎么解锁

达梦数据库在并发场景下如果出现事务未提交、SELECT FOR UPDATE没释放、或者长事务一直挂着，很容易把表锁住。在DataGrip里执行UPDATE或DELETE时会一直卡住，甚至报锁等待超时。

我第一次遇到这情况，以为是数据库挂了，后来才发现是同事在另一台机器上开了一个事务，忘了提交。排查方法如下。

在DataGrip里执行查询锁信息的SQL：

SELECT * FROM v$lock;

这个视图会返回当前数据库中的锁信息，但字段是数值形式的，没经验不太好定位。更直观的做法是查活动会话：

SELECT * FROM v$sessions WHERE state = 'ACTIVE';

通过会话信息可以定位到具体是哪个用户、哪台机器、执行了什么SQL，然后再决定要不要终止这个会话。

确认是要终止的会话后，执行：

SP_CLOSE_SESSION(会话ID);

或者用：

ALTER SYSTEM KILL SESSION '会话ID';

这里一定要看清楚，别把DBA自己正在跑的监控会话给杀了。我建议解锁之前先跟会话所有方确认，尤其是生产环境。另外，锁表的根源不解决，解锁也只是治标，真正要做的是让业务代码里的事务短平快，避免大事务长期占用资源。

5.2 中文乱码的处理

DataGrip连达梦查数据，中文显示成问号，这个问题几乎是新人必踩。

乱码的原因一般是客户端和服务端字符集不一致。达梦数据库在初始化时可以指定字符集，很多老系统用的是GBK或GB18030，而DataGrip默认按UTF-8来处理，两边一碰撞就乱码。

处理办法分几步：

1. 先确认数据库字符集，在达梦管理工具里可以查到，或执行SELECT * FROM v$parameter WHERE name LIKE '%charset%'
2. 如果库字符集是GBK，而你的DataGrip显示乱码，可以在连接URL后面加参数，但达梦JDBC对指定字符集参数的支持跟MySQL不完全一样。实际操作中我建议直接在连接的高级属性里设置：字符集相关参数，比如characterEncoding=UTF-8或按库实际编码设置
3. 最彻底的方案：让团队老师把库字符集统一成UTF-8，新库建库时直接选UTF-8，老库迁移时做字符集转换。GBK和UTF-8混杂的环境，工具层面怎么配都别扭

另外，DataGrip的File Encoding要统一设置成UTF-8，特别是从外部导入SQL脚本时，如果脚本文件本身是GBK编码，要把文件编码切对再执行，否则SQL里的中文注释和中文字符串字面量也会变成乱码。

5.3 导入DMP文件，DataGrip不是首选

网络上经常搜到"达梦数据库dm导入dmp"的问题。如果只有几百KB的小脚本，DataGrip直接执行没问题；但如果是整库导入DMP文件，别指望DataGrip能搞定。

达梦官方提供了独立工具：dexp（导出）和dimp（导入），还有图形化的DM管理工具。在DM管理工具里可以右键"导入"选择DMP文件，速度和稳定性都比自己写脚本强得多。实际操作中，大库导入前要注意表空间是否足够，导入日志要开启，失败时能定位到具体对象。

所以我的习惯是：日常查询、开发、调试用DataGrip；备份恢复、批量导入导出用DM管理工具或命令行工具。工具各司其职，不要指望一个工具包打天下。

5.4 达梦DW和DSC架构下的连接差异

如果你所在项目的达梦数据库是高可用架构，可能会遇到连接方式上的变化。达梦的DW（数据守护）是主备架构，DSC（共享存储集群）类似Oracle RAC的集群架构。这两种架构下，应用连接数据库的URL可能走的是服务名或特定端口，不再是简单的单机5236端口。

在DataGrip中连接这类架构时，驱动本身不变，但需要确认DBA提供的连接地址和端口到底是直连主库，还是一个负载均衡的接入点。我之前遇到过一个DSC环境的连接串，服务端只开放了特定端口给客户端，直接把连接测试超时。后来找DBA拿到正确的接入地址才连上。所以连接前先问清楚部署架构，能少走很多弯路。

6. 进阶配置：SSH跳板、只读模式和团队协作

前面讲的是基础连接，但实际项目里往往还有跳板机、生产环境、多人协作这些场景要处理。这一节分享几个DataGrip配合达梦的进阶配置思路。

6.1 通过SSH隧道连接跳板机后面的达梦

很多公司的数据库服务器不直接对外网开放，要通过跳板机（堡垒机）中转才能访问。这时候DataGrip的SSH/SSL配置就派上用场了。

在数据源编辑界面，切换到SSH/SSL标签页，勾选"Use SSH tunnel"，填写跳板机的地址、端口、用户名和认证方式（密码或私钥）。DataGrip会先把连接通过SSH隧道转发到达梦服务器，然后再执行数据库协议。这样本机不需要跟达梦服务器直接网络互通，只要跳板机能访问数据库就行。

这个配置我记得很深刻，因为第一次配的时候跳板机的私钥权限不对，SSH一直弹认证失败。后来把私钥文件权限改成600（Linux上）才通过。

6.2 用只读模式保护生产环境

在生产环境排查问题时，手一抖执行了DELETE或UPDATE且没有WHERE条件，这种事情谁都不想经历。DataGrip对数据源可以设置只读模式，开启后任何修改操作都会被IDE拦截。

设置路径：数据源属性 → Options → Read-only。打开后，执行INSERT、UPDATE、DELETE、DDL语句都会报错，只允许SELECT查询。我个人的建议是：凡是连生产环境的连接，一律开只读；真的需要写操作时，临时关掉并确认当前在干吗，操作完马上开回去。

这个习惯救过我很多次。尤其是一边开着好几个窗口，一边排查问题的时候，只读模式就像一个安全带。

6.3 元数据刷新慢的优化

达梦数据库对象多时，DataGrip第一次展开数据库树会很慢，动辄十几秒甚至几十秒。原因是要从系统视图拉取所有表、视图、字段、索引的元数据。优化办法：

• 在数据源属性的Schemas标签页里，只勾选自己需要操作的那几个Schema，不要全选
• 右键数据源，选择"Refresh"时，尽量精确到某个Schema，不要每次都全库刷新
• 如果连接后只是写SQL测试，可以直接打开Console写SQL，不依赖左侧对象树的加载

实际体验下来，按Schema缩小范围之后，元数据刷新基本能控制在两秒以内。

6.4 团队统一数据源配置

最后说一个团队协作的细节，而且我觉得特别值钱：DataGrip支持把数据源配置导出为文件，后缀是.dsp（或.dsx）。团队可以用Git管理这份配置文件，新同事克隆仓库后直接导入，就能拿到统一的数据库连接配置，不用再手把手教每个人填IP、端口、Schema。

具体操作：在数据源列表里选中一个数据源，右键或通过工具菜单选择"Export Data Sources"，生成配置文件；新同事这边选择"Import Data Sources"导入即可。注意，配置里包含用户名密码，用团队私有仓库管理或者导入后再改密码都可以，别把生产密码明文推到公开仓库里。

这个做法对团队效率的提升特别明显，尤其是达梦这种非主流驱动，每个人从头配置一遍既费时又容易出错。一份共享配置，五分钟就能让所有人跑起来。

最后再说一点实际操作中的体会。达梦数据库跟DataGrip磨合的关键，其实不在于DataGrip本身，而在于驱动版本是否匹配、URL是否按达梦习惯来写、Schema和权限是否理清楚。把这几个基础问题解决掉，它的使用体验和Oracle几乎没有差别。如果你正在做国产数据库适配，或者只是临时需要从达梦导数据出来分析，照着这篇文章操作，一个小时内应该就能在DataGrip里顺利跑通达梦的查询。