MyBatis多数据源配置怎么实现？，多数据源动态切换配置方法详解

MyBatis多数据源配置的核心在于将“数据源”、“SqlSessionFactory”、“事务管理器”三个维度按业务域拆分，并通过动态数据源路由或分包策略实现读写分离与垂直分库。 在Spring Boot环境下，推荐优先使用@DS注解配合AOP动态切换，而非硬编码多套SqlSessionTemplate，这样既能降低耦合，又能保证事务边界清晰，对于中小团队而言，与其追求复杂的分布式事务方案，不如先通过“分包+主从分离”解决90%的实际问题。

为什么需要多数据源

在单体应用向微服务演进的过程中,单一数据库往往无法满足性能与隔离需求，典型场景包括：

• 读写分离：主库负责写，从库负责读，减轻单库压力。
• 业务分库：用户库、订单库、日志库各自独立，避免相互影响。
• 第三方系统对接：需要同时访问多个遗留系统数据库。

如果硬编码多套SqlSessionFactory,会导致代码冗余、事务错乱、维护成本飙升。正确思路是让数据源切换对业务代码透明，通过注解或配置声明式路由。

主流实现方案对比

综合来看，动态数据源路由是性价比最高的方案，尤其适合大部分业务系统。

手写动态数据源路由（核心实战）

定义数据源枚举与上下文

public enum DataSourceType {
    MASTER, SLAVE
}
public class DynamicDataSourceContextHolder {
    private static final ThreadLocal<DataSourceType> CONTEXT = new ThreadLocal<>();
    public static void set(DataSourceType type) { CONTEXT.set(type); }
    public static DataSourceType get() { return CONTEXT.get(); }
    public static void clear() { CONTEXT.remove(); }
}

实现动态数据源类

public class DynamicDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return DynamicDataSourceContextHolder.get();
    }
}

配置多数据源

在application.yml中配置主从库连接，然后构建DataSource、SqlSessionFactory与PlatformTransactionManager。关键点：必须使用@Primary标识默认数据源，避免Spring装配歧义。

定义切换注解与AOP切面

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface DS {
    DataSourceType value() default DataSourceType.MASTER;
}

在切面中拦截注解,切换上下文，并在方法结束后清理ThreadLocal。注意：事务开启的时机优先于切面，因此必须保证切换数据源在事务启动前完成，否则事务管理器会用之前的数据源连接。

常见坑与专业解决方案

坑1：事务内切换失效

如果@Transactional和方法上的

@DS同时存在，Spring事务管理器会提前获取连接，导致切换无效。

解决方案：

• 将@DS放在Service层外部调用入口，而不是被事务方法内部调用。
• 使用TransactionSynchronizationManager手动绑定资源，或者通过DataSourceTransactionManager的DataSource代理实现。

坑2：连接池耗尽

动态切换时,如果忘记清理ThreadLocal，或AOP顺序错误，可能导致连接泄漏。

解决方案：

• 在@AfterReturning和@AfterThrowing中显式调用clear()。
• 使用try-finally包裹业务方法，确保清理。

坑3：多数据源事务管理混乱

最佳实践是：将写操作与读操作拆分成独立事务边界，避免跨库事务。 若确实需要强一致，应引入Seata等分布式事务中间件，而不是在本地强行处理。

酷番云实战经验案例

我们在酷番云上部署某电商客户系统时,客户使用了一主两从的MySQL架构，业务量集中在订单与商品模块。我们没有选择微服务拆分，而是直接利用酷番云提供的云数据库实例，在同一个应用内配置多数据源。

具体做法：

• 主库托管写操作，实例规格为4核8G，酷番云的高IO云盘支撑高并发写入；
• 两个从库分别承担订单查询和商品搜索，利用酷番云的只读实例自动同步，并开启连接池监控；
• 通过自定义@DS注解，在Service层按方法粒度切换，订单查询走从库，下单逻辑走主库。

效果：读峰达到12000 QPS时，主库CPU仅40%，整体响应时间下降65%。

而且酷番云的数据库运维控制台帮我们自动检测慢查询，后续我们又针对高频查询增加了本地缓存，进一步减轻从库压力。

这个案例说明：多数据源并不需要复杂架构，关键是合理利用云基础设施和良好的代码规范。

相关问答

问1：多数据源下MyBatis的分页插件如何正确配置？

答： 分页插件（如PageHelper）会自动拦截Executor，在多数据源环境下，必须为每个SqlSessionFactory单独配置插件，否则会报ClassCastException或分页失效。推荐使用MyBatis-Plus的PaginationInnerInterceptor，并将其注入到每个SqlSessionFactoryBean的plugins属性中。 确保分页插件优先于数据源路由执行，即先确定当前数据源，再发起查询。

问2：如何监控多数据源的健康状态？

答： 建议使用Druid或HikariCP的监控能力。Druid内置了数据源监控页面，可以实时查看每个数据源的连接数、活跃连接和SQL执行频率；HikariCP则可通过dropwizard-metrics暴露指标。 可以定期执行SELECT 1作为健康检查，并接入日志平台，当某一数据源连续失败时，自动触发熔断机制，切换到备用节点。

互动

如果您在实际配置中遇到过“数据源切换失败”或“事务不回滚”的问题，欢迎在评论区留言您的场景，我们会一一给出具体排查思路，如果觉得本文对您有帮助，请点赞并转发给更多需要的朋友，后续将推出“分布式事务与多数据源整合”的进阶内容。关注我，获取更多数据库架构实战经验。