SpringBoot集成达梦数据库多数据源配置实战与踩坑记录

先交代一下我遇到的现状。年初我接手了一套内部订单履约系统的适配改造，原工程从数据库到 SQL 都是围绕 MySQL 写的，业务还在稳定运行；可后台上报表、审计查询那边又硬性要求使用达梦数据库。因为系统不能停机迁移，MySQL 库也不会马上废弃，结果就是同一个 SpringBoot 工程里必须同时存在 MySQL 和达梦两套数据源，默认继续读写 MySQL，只有做报表同步和审计查询时才让连接切到达梦。这种模式在工程圈里不稀奇，可当你真正操作时，会发现网上很多配置是“同一篇博客互相抄”，连驱动类名都是错的。我把这次改造的配置方式、踩坑记录和排错思路完整整理出来，给那些正在做同类国产数据库适配的朋友一个能直接抄的作业。

1. 接到改造需求后，我先把数据源边界画清楚了

1.1 多数据源不是往 yml 里塞两个配置那么简单

先说结论：多数据源方案的难点从来不在“连接池怎么创建”，而是“什么时候走哪个库”的规则必须足够可控。

很多第一次接触的人容易陷入一个误区，以为在 spring.datasource 下面配两个 url 就能自动多库。实际上一套 SpringBoot 工程里，数据源这个基础设施会被 MyBatis、事务管理器、连接池等一堆组件引用；你如果只是裸配了两个 DataSource Bean，Spring 根本不知道哪个库是主库，事务管理器不知道该绑谁，MyBatis 也不知道该从哪个数据源拿连接。最终要么启动报错，要么所有 SQL 都落在一个数据源上。

我在这次改造里没有自研数据源路由，直接用动态数据源组件来做切换。它本质上是把 Spring 自带的 AbstractRoutingDataSource 那套机制封装好了：启动时按照配置创建多个真实数据源，运行时通过一个 ThreadLocal 保存当前操作要用的 key，DataSource 在 getConnection 时根据 key 路由到对应库。这样业务侧写代码非常自然，你想要某个方法走达梦，加一个注解就行。

选型时我对比过两条路线，差异挺明显：

• 自研 AbstractRoutingDataSource：代码量不算大，核心是继承类并重写 determineCurrentLookupKey()，但坑在于事务管理、连接池监控、MyBatis 插件都要自己处理，团队里每个人理解不一致后代码很容易失控。
• 使用 dynamic-datasource-spring-boot-starter 这类的开源封装：好处是分组、注解切库、多数据源事务边界都替你考虑过了，社区案例也多，遇到问题能找到答案。

我的建议是：如果不是团队闲着没事想练手，没必要重复造轮子。用经过验证的组件，把精力留给后续 SQL 方言改造，这样才划算。

1.2 先约定好数据流向，代码才不会写乱

动手配置之前，我先梳理了一下业务场景，其实就三类：

• 订单主流程的增删改查，仍然走 MySQL 老库，不能因为新增达梦而让日常交易受到影响，所以它永远是默认数据源。
• 后台的报表汇总、审计数据同步，统一走达梦库，数据以只读查询或定时任务落库为主。
• 还有一类特殊处理是“同一条业务数据先在 MySQL 更新，再把最近状态同步给达梦报表库”，这种跨库写入需要靠定时任务或消息队列解耦，不能直接在同一个事务里并发操作两个库。

把这个规则定义清楚后，再去看代码模块划分就简单了。我把达梦相关操作独立成 audit 包，所有 Mapper 接口都在这个包里，Service 层入口方法上统一加达梦数据源注解，不允许在其他业务包内直接 new 连接或另写 JdbcTemplate 访问达梦。这样做虽然看起来“不够灵活”，但维护上非常省心，后面排查问题时，只要看到 audit 包外的代码在操作达梦，第一反应就是架构违规，而不是配置问题。

2. 搭建工程骨架：驱动依赖、主配置与最小验证

2.1 达梦驱动坐标并没有放在中央仓库里

这是整个接入过程里最容易让人卡住的一步。MySQL 有官方维护的 mysql-connector-j，引入坐标即可；但达梦 JDBC 驱动一般不会直接发布到 Maven Central，需要从达梦数据库安装目录里拿。

我用的达梦 8 版本，驱动 jar 通常在安装路径下的 drivers/jdbc 目录里，常见的文件名是 DmJdbcDriver18.jar。这个文件名并不是固定不变的，某些发行版可能叫 DmJdbcDriver8.jar，但内部驱动类一样。拿到 jar 后先安装进本地 Maven 仓库，命令如下：

bash复制mvn install:install-file -Dfile=/opt/dmdbms/drivers/jdbc/DmJdbcDriver18.jar \
    -DgroupId=com.dameng \
    -DartifactId=DmJdbcDriver \
    -Dversion=8.1.3.140 \
    -Dpackaging=jar

然后在 pom 里引入依赖：

xml复制<dependency>
    <groupId>com.dameng</groupId>
    <artifactId>DmJdbcDriver</artifactId>
    <version>8.1.3.140</version>
</dependency>

这里有两个点要提醒。第一，如果你在公司内网开发，还要把同一个 jar 部署到内网 Nexus/Artifactory 私服，否则同事本地构建时会因为找不到依赖而怀疑人生。第二，SpringBoot 版本和达梦驱动的搭配需要小心。我这边用的 SpringBoot 2.7，这套驱动完全没问题；如果项目用了 SpringBoot 3.x，请选择动态数据源针对 Boot3 的 starter 版本，别拿 Boot2 的依赖硬塞进去。

2.2 yml 第一版配置长这样

我用的是 HikariCP 作为连接池，yml 配置如下：

yaml复制spring:
  datasource:
    dynamic:
      primary: mysql
      strict: false
      datasource:
        mysql:
          driver-class-name: com.mysql.cj.jdbc.Driver
          url: jdbc:mysql://localhost:3306/order_platform?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
          username: order_app
          password: order_app@2024
          hikari:
            maximum-pool-size: 20
            minimum-idle: 5
        dm:
          driver-class-name: dm.jdbc.driver.DmDriver
          url: jdbc:dm://192.168.10.22:5236
          username: AUDIT_USER
          password: Audit@123
          hikari:
            maximum-pool-size: 10
            minimum-idle: 2

几个关键配置说明一下：

• primary 指定默认数据源，不写 @DS 注解时走的是 MySQL，这样老代码几乎不用改。
• strict 我建议调试阶段设成 true，如果代码里写了一个不存在的 key，启动后能立刻报错暴露问题，而不是悄悄退回默认库。业务稳定后再看情况切回 false。
• 达梦数据库默认端口是 5236，URL 一般写成 jdbc:dm://ip:port，不要在末尾强行加一个类似 MySQL 格式的库名路径，这点后面会详细说。

2.3 用一个最小接口验证连接是否打通

配置完成后，我习惯先写一个极小的接口验证连通性，避免一上来就接复杂业务。达梦兼容 Oracle 语法，可以直接用 DUAL 表。

java复制@Mapper
public interface DmConnCheckMapper {

    @Select("SELECT 1 AS RESULT FROM DUAL")
    Integer checkConnection();
}

Controller 或测试类里调用时，加上 @DS("dm")：

java复制@RestController
@RequestMapping("/health")
public class HealthController {

    @Autowired
    private DmConnCheckMapper dmConnCheckMapper;

    @GetMapping("/dm")
    @DS("dm")
    public Integer checkDm() {
        return dmConnCheckMapper.checkConnection();
    }
}

浏览器请求 /health/dm，返回 1 就说明连接通路已经没问题。这一步看似简单，却能帮你把配置错误和后续业务 SQL 错误彻底分开，排查问题时不至于两边混在一起。

3. 达梦和 MySQL 的差异点，绝大部分问题都出在这里

3.1 驱动类名为什么网上说法不一

配置达梦数据源时，最常被问到的就是 driver-class-name 到底填什么。我确认过达梦 8 官方 JDBC 示例，正确的驱动类是 dm.jdbc.driver.DmDriver，不是 com.dm.jdbc.DmJdbcDriver，也不是其他什么奇怪的名字。

网上很多旧帖子照抄成了 com.dm.jdbc.DmJdbcDriver，如果你看到 ClassNotFoundException: com.dm.jdbc.DmJdbcDriver，基本就是驱动类名填错了。把配置改回标准写法即可：

yaml复制driver-class-name: dm.jdbc.driver.DmDriver

另外，启动时报“找不到驱动”时不要只怀疑类名。先用 Maven 检查依赖是否真的进入 classpath：

bash复制mvn dependency:tree | grep DmJdbcDriver

如果依赖树里能看到对应 jar，再检查是不是配置里引了多个数据源 but 只有其中某个写错了驱动。这个 ClassNotFound 现象在动态数据源场景下有迷惑性，因为报错堆栈可能指向的是 Dm 连接池初始化，而不是你写的 Mapper。

3.2 URL 里要不要带库名或 schema

这是 MySQL 开发转达梦时最别扭的地方。MySQL 的 JDBC URL 一般会带上库名，例如 jdbc:mysql://localhost:3306/demo，但达梦的连接规范并不是这样理解“库”的。

达梦里，一个登录用户通常对应一个模式（Schema），用户名本身就是进入模式的钥匙。所以正常写法是：

text复制jdbc:dm://192.168.10.22:5236

如果你写成 jdbc:dm://192.168.10.22:5236/AUDIT_DB 这类带斜杠库名的形式，很可能会报连接失败、库不存在或类似错误，反而把自己搞懵。

但这不代表你无法访问其他模式下的表。假设当前登录用户是 AUDIT_USER，你想读取 SYSDBA 用户下的报表，SQL 里可以用 SYSDBA.REPORT_DAY_SUMMARY 这类“用户名.表名”的方式访问，前提是 DBA 已经授权给 AUDIT_USER。这在多数据源业务里非常实用，因为不同达梦用户之间的表默认是隔离的，不像 MySQL 里多个库在同一个连接下可以随便切换。

3.3 大小写敏感与反引号问题

达梦的默认行为保留了很多 Oracle 风格。建表时不加双引号的表名、字段名会被统一存储为大写，而 MySQL 开发者习惯了用小写建表，或者直接在 SQL 里写反引号括起来的表名，例如：

sql复制SELECT * FROM `order_info` WHERE `status` = 1;

这段 SQL 在 MySQL 里没问题，放到达梦 8 下如果不开启 MySQL 兼容模式，大概率会直接语法报错。达梦不支持把反引号当作标识符边界，正确做法是把表名字段名改为大写或普通标识符：

sql复制SELECT * FROM ORDER_INFO WHERE STATUS = 1;

更稳妥的方案是让 MyBatis XML 里的 SQL 走标准写法，不要堆 MySQL 特有语法。同一个 Mapper XML 很难做到“MySQL 和达梦都完美执行”，最省事的方案是达梦相关表单独建一套 Mapper 接口和 XML，写专用的达梦方言 SQL。不要指望一套 SQL 两头通吃，除非你的 SQL 足够简单。

4. 切换数据源的正确姿势与常见反模式

4.1 注解加到 Service 层，而不是散落到 Mapper 里

动态数据源组件支持把 @DS 加在类或方法上，我推荐统一加在 Service 实现类的方法上。这样业务入口对数据源的选择是显式的，谁在什么场景下走达梦一目了然。

一个典型写法：

java复制@Service
public class AuditReportServiceImpl implements AuditReportService {

    @Autowired
    private AuditReportMapper auditReportMapper;

    @Override
    @DS("dm")
    public List<ReportRow> queryDailyReport(String date) {
        return auditReportMapper.selectDailyReport(date);
    }
}

如果业务简单到直接调 Mapper 就能出结果，有人会把 @DS("dm") 加到 Mapper 接口上，这样也能跑通。但我建议别这么做，因为 Mapper 是数据访问层，你无法预判它未来会被哪种业务场景调用。今天这个 Mapper 只查达梦，明天另一个 MySQL 业务也想复用同一个查询逻辑，那注解就变成了隐患。把数据源选择权放在 Service 层，将来拓展时只需要调整方法上的注解即可。

4.2 代码里手工切换时要记得释放上下文

有些场景下注解并不方便，比如在一个循环里要交替查询达梦和 MySQL，或者要根据用户请求参数决定访问哪个库。这时候可以用动态数据源组件提供的上下文工具手工切换。

java复制DynamicDataSourceContextHolder.push("dm");
try {
    // 这里执行的数据库操作都会走达梦
    List<ReportRow> rows = reportMapper.selectList(...);
} finally {
    DynamicDataSourceContextHolder.poll();
}

注意一定要在 finally 里调用 poll() 清理上下文，否则当前线程的下一次复用会继续带着旧的 key，导致后续请求“莫名其妙串库”。这类 bug 在生产环境非常隐蔽，因为正常请求可能第一次是走对了库，第二次线程复用时却走到了上一次的库。

4.3 同一个 Service 内部调用不会经过代理

@DS 本质上还是基于 Spring AOP 做的方法拦截，它只能拦截从 Spring 容器里拿到的代理对象。如果你的 Service 里写了这种代码：

java复制public void syncData() {
    queryDm(); // this.queryDm()
}

@DS("dm")
public void queryDm() {
    // 想切换到达梦
}

在 syncData 内部直接用 this 调用 queryDm()，注解不会生效，因为 this 是原始对象，不是 Spring 生成的代理。很多人把 @DS 加在私有方法或者同类内部调用方法上，结果发现数据源始终没切换，就是这个原因。

正确做法要么把目标方法放到另一个 Spring Bean 里，通过注入对象去调用；要么直接使用上下文工具手工切换。

5. 实战中的报错排查：五个现场记录

5.1 现场一：SpringBoot 版本太高，动态数据源 starter 注入失败

第一次搭建时，我用的是刚创建的 SpringBoot 3.3 工程，直接引入了网上常见的 dynamic-datasource-spring-boot-starter，启动就报了一个类似 No qualifying bean of type DynamicDataSourceProvider 的错误。查了半天，发现问题是 starter 的命名和版本没有匹配 SpringBoot 3 的 Jakarta 体系。

SpringBoot 2.x 项目一般用普通 starter 没问题，但 SpringBoot 3.x 项目要用官方提供的 Boot3 专用 starter。我也遇到过有同事把 4.0 以上版本的 starter 强制塞进 SpringBoot 2.7 工程，结果同样跑不通。所以当出现各种莫名其妙的注入失败、找不到数据源类型时，先核对 SpringBoot 主版本和动态数据源 starter 版本，别着急改业务代码。

5.2 现场二：Hikari 初始化连接池时 driver not found

这个报错信息通常是：

text复制Failed to configure a DataSource: 'url' attribute is not specified

或者 Hikari 直接抛出 java.sql.SQLException: driver not found。我当时检查了半天才发现不是 URL 没配，而是动态数据源配置的层级缩进写错了，把 dm 数据源写到了 spring.datasource 下而不是 spring.datasource.dynamic.datasource 下，导致组件找不到 dm 驱动。

规避方法很简单，打开 yml 时注意层级，用 IDE 的缩进提示确认，别凭肉眼。如果依赖检查过、驱动类名也对，仍然报 driver not found，还可以看一下是不是某个数据源类型被配成了 DruidDataSource，而 Druid 的 filter 或类型不认达梦驱动，这时候先统一换成 HikariCP 做最小验证，跑通后再去调连接池高级参数。

5.3 现场三：连接报了“表或视图不存在”，但数据确实存在

这个误报很坑。当时我们想让达梦用户 AUDIT_USER 直接查询 SYSDBA 下的报表，但 SQL 里只写了表名 REPORT_DAY_SUMMARY，结果数据库一直报“表或视图不存在”。一开始我还以为是权限缺失，找人看权限后才发现，达梦里同名的表属于不同模式，单写表名时数据库默认去当前用户自己的模式里找，查不到就报不存在。

后来把 SQL 改成带模式前缀的写法就正常了：

sql复制SELECT * FROM SYSDBA.REPORT_DAY_SUMMARY WHERE STAT_DATE = '2025-11-01';

这也提醒了一个连接池层面的问题：如果你在达梦里曾经用 ALTER SESSION SET CURRENT_SCHEMA = XXX 这类方式切过模式，请确认连接归还给连接池之后这个 session 状态是否会被清理；如果清理不彻底，下一次请求可能带着别人的 schema 状态，出现更难排查的串数据问题。我的建议是不要依赖连接池复用 session 的状态，每个关键查询都在 SQL 层面写清楚模式名前缀。

5.4 现场四：MyBatis-Plus 分页插件默认用了 MySQL 方言

我们工程里大量依赖 MyBatis-Plus 的分页能力，默认情况下分页插件拦截 SQL 后会根据数据源类型生成不同方言。但如果没有把达梦的方言加进去，可能会导致达梦 SQL 被错误地拼成 LIMIT 或 Oracle 的老式分页，结果报表页每页数据都对不上，甚至某些写法直接报 SQL 语法错误。

解决方法是给 MyBatis-Plus 分页插件单独指定达梦方言：

java复制@Bean
public MybatisPlusInterceptor mybatisPlusInterceptor() {
    MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
    PaginationInnerInterceptor pagination = new PaginationInnerInterceptor();
    pagination.setDbType(DbType.DM);
    pagination.setMaxLimit(500L);
    interceptor.addInnerInterceptor(pagination);
    return interceptor;
}

这样分页插件碰到达梦数据源时，会生成达梦兼容的分页 SQL，不再错误地套用 MySQL 语法。顺带一提，如果只想针对某个数据源做分页限制，也可以在 yml 或代码里单独配置，但大多数人用一个全局拦截器就够了，别过度设计。

5.5 现场五：报错 “Cannot determine target DataSource for lookup key”

这类报错的意思很直白：代码里希望切换到名为 dm 或 audit-dm 的数据源，但配置里没有这个名字。我见过三种常见原因：

• @DS 注解的值写错了，比如实际配置是 dm，代码里写成了 dm1。
• yml 配置的值前后带了空格，例如 dm ，虽然肉眼几乎看不出来，但 key 匹配不上。
• 刚加了新数据源但忘记重启应用，动态数据源组件的配置并不会自动热加载。

排查时可以在启动日志里搜索当前动态数据源加载了哪些 key，确认实际可用的数据源名称，再把注解值对齐，问题基本就解决了。

这几类错误用表格整理一下，方便以后直接对照：

6. 多数据源场景下的事务边界，一定要单独治理

6.1 别指望一个 @Transactional 同时搞定 MySQL 和达梦

多数据源常见的问题是有人把两套库的写入放到同一个方法，再统一加 @Transactional。比如先写 MySQL 订单表，再写达梦报表表，都包在一个事务里。表面上看如果第二步失败，第一步能回滚；可实际上跨数据库事务要么依赖 XA 分布式事务，要么引入 Seata 这类方案，普通 @Transactional 根本做不到跨库强一致。

在动态数据源组件里，事务一旦开启，事务管理器会拿到一个物理连接；如果后续代码切换数据源，新请求的连接和当前事务不是同一个库，就会出现类似“数据源路由没生效”的诡异现象。我的做法是：

• 尽量把跨库操作拆成多个独立方法，各自管理自己的事务。
• 对于“MySQL 写入后同步到达梦”这种需求，优先用本地消息表或 MQ 做最终一致，不要强求一个方法内完成。
• 如果确实要在同一次请求里先后访问两个库，至少要在每个 Service 方法上显式标注 @DS，并且理解事务传播机制。默认 REQUIRED 传播级别下，内部方法如果加入已有事务，可能无法重新选择数据源，这时可以考虑用 REQUIRES_NEW 开启新事务，让切换点落在新连接上。

6.2 事务边界和 @DS 注解的叠加规律

我实际遇到的一个例子是这样的：Service A 不加 @DS，方法内调用了 Service B，Service B 的 query() 方法上加了 @DS("dm")，两个方法都没有额外事务配置。此时 Spring 代理生效，B 方法会切换到 dm 数据源，并在方法结束后恢复。这符合大多数人的直觉，代码也能跑通。

可一旦 A 方法上加了 @Transactional，情况就变了。A 开启事务后，连接资源已经绑定到 MySQL（默认数据源），随后 B 方法的 @DS 如果只是加入已有事务，它可能无法再换到 dm。也就是说，“事务”和“切换”两套逻辑叠加时，外层的传播机制会限制内部切换。遇到这种怪现象时，我推荐先去掉 A 方法的事务边界，或者把 B 方法改成 REQUIRES_NEW，让 B 独立开一个事务，这样 @DS 才能真正在 B 的范围内生效。

这个细节很容易被忽略，因为报错不会直接提示“无法切换数据源”，而是表现为 B 查询的数据不对，或者干脆报表找不到。排查时不要只盯 SQL，先想想当前线程外层是否开启了事务。

6.3 连接池参数建议按库区分

多数据源连接池如果参数照搬，可能因为达梦报表查询特别重而拖垮 MySQL 主业务。我在这次改造里把达梦连接池单独调小了，最大连接数只有 10，空闲连接数 2；MySQL 主连接池则保持 20。这样即使某个报表 SQL 因为统计逻辑太重而把达梦连接耗尽，影响范围也被限制在报表模块。

另外建议达梦数据源的连接验证 SQL 用达梦兼容的语法，比如 SELECT 1 FROM DUAL。Hikari 默认的 connection-test-query 如果不设置，可能走 JDBC 驱动的 isValid() 逻辑，这在不同驱动下表现不一，手工指定测试 SQL 能减少连接池误判。

7. 接入完成后的完善动作：方言适配与长期维护

7.1 需要准备的数据库专项检查清单

接入后真正花时间的不是配置，而是让业务 SQL 在两个数据库上表现一致。我按下面的清单逐项核对了一遍：

• 分页：达梦相关接口是否都走 MyBatis-Plus 且分页插件配置了 DbType.DM。
• 主键：MySQL 自增主键和达梦 IDENTITY 字段在 XML 里的主键生成策略是否一致；批量插入时达梦获取自增主键的写法是否兼容。
• 时间函数：NOW()、CURDATE() 这些 MySQL 函数在达梦里无法直接用，应改为 SYSDATE、CURRENT_TIMESTAMP 这类标准写法。
• 字段类型：TINYINT 和达梦的 SMALLINT 要按实际语义对应，避免 Java 的 Boolean 类型在映射时出错。
• 模糊查询：CONCAT('%', #{keyword}, '%') 这种写法两库通用，但如果直接用了 MySQL 的 LIKE BINARY 之类的扩展语法，达梦就会翻车。

如果你维护的 SQL 量很大，不可能逐条检查，那么最好的控制手段是限制达梦 Mapper 的开发范围，不允许在达梦相关模块里直接复用 MySQL 的 XML，单独建一套 audit/mapper 目录专门维护达梦 SQL，代码评审时重点看跨库逻辑。

7.2 关于驱动版本的最后一句话

整个改造过程中我强烈体会到一件事：达梦 JDBC 驱动的版本会影响很多怪异现象，尤其是 CLOB 读取、时间戳精度、连接池校验这些底层细节。如果业务代码和配置看起来都对，但某些接口偶发报错，先查一下 drivers/jdbc 目录下的驱动 jar 是不是最新补丁版，换一个已知稳定的驱动版本，很多诡异问题可能直接消失。

7.3 保持数据源路由的可观测性

最后提一个平时容易忽略但长期维护很重要的点：给多数据源路由加日志。我在连接池配置里把达梦数据源的 hikari.pool-name 设成了可识别的名字，在业务日志里也能通过连接池名称快速定位本次请求到底用的是 MySQL 还是达梦。对开发和排查来说，这个小小的命名习惯比什么都管用。

调试阶段还可以在配置里开启 dynamic-datasource 的切换日志，观察每个方法执行前的数据源 key 变化。等系统上线后，如果怀疑某次调用走错库，只要看日志里有没有出现目标数据源的切换记录，就能很快判断是不是 @DS 没有生效。这个能力避免了很多无意义的 SQL 分析时间。

如果你正在做类似的达梦多数据源接入，建议先不要急着处理各种复杂的 SQL 兼容问题，先把连接跑通、把切换边界控制好、把错误日志留出来，后面的适配工作会顺利得多。