在单体应用逐渐演化为复杂业务系统的过程中，一个数据库往往撑不起全部业务。典型的例子是电商系统里订单数据和用户数据分库存储，或者报表系统需要同时读取业务库和历史归档库。这时候SpringBoot默认的单数据源配置就不够用了，需要让应用同时管理多个数据库连接。本文将详细介绍几种常见的多数据源配置方案，从手动配置到动态切换逐一展开，并说明实际落地时容易踩到的坑。
方案一：配置文件定义多数据源并手动组装
这是最直接也最容易理解的方式。思路是放弃SpringBoot的自动装配，自己在配置类中创建两个DataSource的Bean，然后分别为每个数据源搭建独立的SqlSessionFactory和事务管理器。以application.yml为例，可以这样组织配置：
spring:
datasource:
master:
jdbc-url: jdbc:mysql://127.0.0.1:3306/master_db?useSSL=false
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
slave:
jdbc-url: jdbc:mysql://127.0.0.1:3306/slave_db?useSSL=false
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
注意这里用的是jdbc-url而不是url，因为一旦显式声明了DataSource类型的Bean，SpringBoot的自动配置就会退到后台，此时属性绑定走的是DataSource构造器的方式，HikariCP要求属性名为jdbc-url。如果继续写url，启动时会报找不到驱动的错误，这是新手最常见的坑之一。
接下来写配置类，分别装配两个数据源。核心代码如下：
@Configuration
public class DataSourceConfig {
@Bean(name = "masterDataSource")
@ConfigurationProperties(prefix = "spring.datasource.master")
public DataSource masterDataSource() {
return DataSourceBuilder.create().build();
}
@Bean(name = "slaveDataSource")
@ConfigurationProperties(prefix = "spring.datasource.slave")
public DataSource slaveDataSource() {
return DataSourceBuilder.create().build();
}
@Bean(name = "masterTransactionManager")
public DataSourceTransactionManager masterTransactionManager(
@Qualifier("masterDataSource") DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
@Bean(name = "slaveTransactionManager")
public DataSourceTransactionManager slaveTransactionManager(
@Qualifier("slaveDataSource") DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
}
如果项目使用MyBatis，还需要为每个数据源创建独立的SqlSessionFactory，并通过@MapperScan把不同包下的Mapper接口绑定到对应的数据源。例如把操作主库的Mapper放在com.example.mapper.master包下，操作从库的放在com.example.mapper.slave包下，配置时指定sqlSessionFactoryRef即可。这种按包路径划分数据源的方式结构清晰，代码里不需要任何切换逻辑，出问题时排查起来也比较直观。
该方案的缺点是扩展性一般。如果以后要加第三个、第四个数据源，就需要再写一套几乎重复的配置代码，而且业务代码必须严格按照包路径组织，跨库操作同一个业务方法时无法享受统一事务。
方案二：基于AbstractRoutingDataSource实现动态数据源
当需要更灵活的切换能力时，比如读写分离场景下写操作走主库、读操作走从库，或者需要按租户路由到不同数据库，就轮到AbstractRoutingDataSource登场了。它是Spring JDBC模块内置的抽象类，内部维护一个数据源映射表，每次获取连接前会调用determineCurrentLookupKey方法决定使用哪个数据源。
首先定义一个持有当前数据源标识的工具类，基于ThreadLocal实现线程隔离：
public class DataSourceContextHolder {
private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>();
public static void set(String key) {
CONTEXT.set(key);
}
public static String get() {
return CONTEXT.get();
}
public static void clear() {
CONTEXT.remove();
}
}
然后继承AbstractRoutingDataSource，重写查找key的方法：
public class DynamicDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey() {
return DataSourceContextHolder.get();
}
}
@Configuration
public class DynamicDataSourceConfig {
@Bean
public DataSource dynamicDataSource() {
Map<Object, Object> targets = new HashMap<>();
targets.put("master", masterDataSource());
targets.put("slave", slaveDataSource());
DynamicDataSource ds = new DynamicDataSource();
ds.setTargetDataSources(targets);
ds.setDefaultTargetDataSource(masterDataSource());
return ds;
}
}
使用时只需要在业务方法执行前调用DataSourceContextHolder.set("slave")，后续的数据库操作就会路由到从库。为了使用更优雅，一般会配合自定义注解加AOP切面，在方法上标注@DataSource("slave")，切面在方法执行前设置标识、执行后清理ThreadLocal。这样业务代码完全无感知，切换逻辑集中在一处维护。
需要特别提醒的是ThreadLocal的清理问题。如果切面只设置不清理，在线程池复用线程的场景下，下一个请求可能带着上一个请求的数据源标识执行，造成数据读错库的诡异问题。所以务必在finally块中调用clear方法。另外从库如果配置了多个，还可以扩展为负载均衡路由，通过简单的轮询算法在多个从库key之间轮转。
方案三：借助第三方starter快速集成
如果不想手写这些基础代码，社区有不少成熟的开源组件可以直接使用，比如dynamic-datasource-spring-boot-starter。引入依赖后，在配置文件里声明多个数据源，框架会自动完成路由容器的组装，并内置了@DS注解用于方法级别或类级别的数据源切换：
@Service
public class OrderService {
@DS("master")
public void createOrder(Order order) {
// 写操作走主库
}
@DS("slave")
public List<Order> listOrders(Long userId) {
// 读操作走从库
return orderMapper.selectByUserId(userId);
}
}
这种方式省去了大量样板代码，还额外提供了嵌套切换、读写分离自动切换、动态增删数据源等高级能力，适合追求开发效率的团队。当然代价是引入了第三方依赖，框架升级和SpringBoot大版本适配需要跟随社区节奏，对于强管控的技术团队需要评估这一点。
常见问题与注意事项
事务问题值得单独强调。使用动态数据源时，一旦方法上加了@Transactional，Spring会在事务开启时获取并绑定一个连接，事务内再切换数据源是不会生效的，所有操作仍然走事务开始时锁定的那个库。正确的做法是避免在同一个事务方法内跨库操作，或者采用分布式事务方案（如Seata）来处理跨库一致性。
连接池参数也要分开配置。两个数据源各自持有独立的连接池，最大连接数、超时时间等参数如果配置不当，可能出现某一个库把连接占满而另一个库闲置的情况。建议对每个数据源单独评估压测指标，而不是简单复制同一套参数。此外监控层面要确认Druid或HikariCP的监控页面能分别展示两个池的状态，方便排查连接泄漏。
最后是Bean冲突问题。自己定义了DataSource相关Bean后，如果启动报“expected single matching bean”之类的错误，通常是自动装配的Bean和自定义Bean同时存在导致的，可以通过@Primary标记主数据源，或在排除自动配置类的方式解决。三个方案各有适用场景：数据源固定且数量少用方案一，需要灵活路由用方案二，追求效率用方案三，按项目实际情况选择即可。
SpringBoot多数据源动态数据源DataSource配置修改时间：2026-09-11 19:46:36