大家好，最近在技术群（QQ群）里，有个小伙伴问了我一个极其经典的问题：“我项目里想做读写分离，是用 Hibernate 的分包配置好，还是 MyBatis-Plus 的动态数据源好？为什么我配置了 JPA 多数据源，事务老是报错？”
这其实触碰到了 Java 后端架构中一个非常痛点的领域：多数据源（Multi-DataSource）的管理。
市面上 90% 的教程只教你怎么贴配置，却没告诉你原理。结果就是上线后，要么事务回滚失败，要么切库切了个寂寞。
今天，我们就把 MyBatis、MyBatis-Plus 和 Hibernate 拉到手术台上，从底层源码的角度，彻底讲透它们的区别以及多数据源的最佳解法。
一、 为什么多数据源这么难搞？
在 Spring 的世界里，单数据源是幸福的。容器启动时，创建一个 DataSource，这就好比你只有一张银行卡，刷卡时不需要动脑子。
但当你需要连接多个数据库（比如：主从库读写分离、分库分表、或者连接老系统的遗留库）时，问题就来了：Spring 怎么知道这一行 SQL 该发给谁？
本质上，多数据源的实现只有两条路：
- 静态分包（物理隔离）： 你的
UserMapper永远连库 A，OrderMapper永远连库 B。 - 动态路由（逻辑切换）： 同一个
UserMapper，这一次查库 A，下一次查库 B。
二、 核心原理：Spring 的“魔术师”
无论你用 MyBatis 还是 Hibernate，想要实现动态切换，绕不开 Spring 提供的一个核心类：AbstractRoutingDataSource。
它的原理其实非常简单，就像一个路由器：
- 它内部维护了一个
Map<Object, DataSource>，存了所有可用的真实数据源。 - 它实现了一个方法
determineCurrentLookupKey()。 - 关键点： 当数据库连接被请求时，它会先去调用这个方法，通常是从当前线程的
ThreadLocal中拿到一个 Key（比如 "master" 或 "slave"）。 - 拿着 Key 去 Map 里找，找到谁，就用谁。
听起来很简单？别急，坑在后面。 不同的 ORM 框架对这个“路由器”的兼容性天差地别。
三、 Hibernate (JPA) 的“倔强”
很多用 JPA 的同学尝试用 AbstractRoutingDataSource 做动态切换，往往会撞得头破血流。
为什么？因为 Hibernate 太“智能”了。
Hibernate 有一级缓存（Session）和复杂的上下文管理。在一个事务（Transaction）开启的瞬间，Hibernate 就需要确定 EntityManager，并绑定一个数据库连接。一旦绑定，在这个事务结束前，它通常不会轻易释放或切换连接。
这就导致了一个经典 Bug：你在 Service 层加了注解想切库，但因为事务早已开启，Hibernate 根本不理会你的 ThreadLocal 变动，依然倔强地用着主库的连接。
Hibernate 的最佳解法：分包隔离（Split Packages）
既然动态切换容易出事，那就物理隔离。
- 将所有连接 A 库的 Repository 放在
com.app.repo.primary。 - 将所有连接 B 库的 Repository 放在
com.app.repo.secondary。 - 配置两套
EntityManagerFactory和TransactionManager。
虽然配置繁琐（要写两个 Configuration 类），但这是 JPA 下最稳健的方案。
四、 MyBatis-Plus 的“优雅”
相比之下，MyBatis（及其增强版 MyBatis-Plus）就显得非常轻量级和听话。
MyBatis 执行 SQL 的过程是无状态的，它没有复杂的 Session 缓存包袱。只要在执行 SQL 的那一刻，SqlSessionFactory 拿到了正确的连接，它就能工作。
因此，MyBatis-Plus (MP) 成为了国内处理多数据源的首选。
MP 生态中有一个神器：dynamic-datasource-spring-boot-starter。它的实现原理是 AOP + AbstractRoutingDataSource 的完美结合：
- 注解标记： 在方法上加
@DS("slave")。 - AOP 拦截： 拦截器在方法执行前，把 "slave" 塞进
ThreadLocal。 - 路由执行： 到底层执行 SQL 时，路由器读取
ThreadLocal，瞬间切换数据源。 - 自动清理： 方法结束后，AOP 自动清理
ThreadLocal，防止污染。
五、 原理可视化（点击查看大图）
为了让你更直观地理解，三味画了两张图：
图 1: Spring 动态数据源路由原理 (通用)
图 2: MyBatis-Plus vs Hibernate 多数据源策略对比
六、 抄作业：企业级最佳实践代码
如果你在做互联网业务系统，强烈建议使用 MyBatis-Plus + dynamic-datasource 的组合。这是目前最优雅、代码侵入性最小的方案。
1. 引入依赖 (pom.xml)
<dependency><groupId>com.baomidou</groupId><artifactId>dynamic-datasource-spring-boot-starter</artifactId><version>3.6.1</version>
</dependency>
2. 配置文件 (application.yml)
看，多么清爽！
spring:datasource:dynamic:primary: master # 默认走主库strict: false # 严格模式，匹配不到数据源是否报错datasource:master:url: jdbc:mysql://192.168.1.100:3306/main_dbusername: rootslave_1:url: jdbc:mysql://192.168.1.101:3306/main_dbusername: root
3. 业务代码 (Service)
一个注解搞定切换，谁用谁知道。
@Service
public class OrderService {@Autowiredprivate OrderMapper orderMapper;// 默认走 master，用于写入public void createOrder(Order order) {orderMapper.insert(order);}// 显式声明走从库，用于查询@DS("slave_1")public Order getOrderInfo(Long id) {return orderMapper.selectById(id);}
}
七、 避坑指南（重点！）
如果你一定要在项目中混用（JPA + MP）或者使用多数据源，请务必注意：
- 事务的边界：
@Transactional开启时，连接就已经确定了！不要试图在@Transactional方法内部再去调用加了@DS的方法，不会生效的！ 数据源切换必须发生在事务开启之前。 - 连接泄露： 以前手动写
ThreadLocal切换数据源时，最容易忘记remove()，导致线程复用时带着上一次的脏数据源。使用 MP 的 Starter 可以帮你自动处理这个清理工作。
总结
- Hibernate/JPA： 适合业务逻辑极其复杂、领域模型驱动（DDD）的项目，多数据源建议用分包隔离。
- MyBatis/MyBatis-Plus： 适合绝大多数互联网业务、需要极致 SQL 掌控的项目，多数据源建议用 dynamic-datasource 动态切换。
- 原理： 一切魔法的尽头，都是 Spring 的
AbstractRoutingDataSource和 AOP。
只有懂到底层，才能在报错时从容不迫。
如果你觉得这篇文章让你学到了东西，哪怕是一个知识点，请帮点个赞或者转发给需要的朋友，这对我很重要！
)
