为什么企业级系统必须掌握Spring Boot 3.2动态数据源切换？
最近和几个做电商中台的朋友聊天，发现大家都在头疼同一个问题：用户量激增后，单数据库扛不住压力，分库分表、多租户隔离这些需求必须上，但动态数据源切换总出幺蛾子——要么切换不生效，要么事务回滚失败。其实，Spring Boot 3.2针对数据源管理做了不少优化，比如增强了AbstractRoutingDataSource的兼容性，还调整了事务管理器的默认行为，掌握这些新特性，能少踩80%的坑。
动态数据源切换的3大典型企业场景
先别急着看代码，搞清楚为什么需要动态数据源更重要。企业里最常见的3种场景：
举个真实案例：某物流企业的TMS系统，之前用Spring Boot 2.7做动态数据源，结果大促期间频繁出现“读请求打到主库”的问题，导致主库压力骤增。升级到3.2后，通过新的DataSourceRouting策略，自动根据SQL类型（SELECT/INSERT）路由，问题直接解决。
Spring Boot 3.2动态数据源实现：从配置到落地
知道了场景，接下来是核心——怎么在3.2里实现？分4步走，每一步都要注意3.2的新变化。
Spring Boot 3.2推荐用DataSourceProperties结合HikariDataSource配置多数据源，和2.x最大的区别是：3.2默认关闭了spring.datasource.primary的隐式主数据源识别，必须显式指定。
比如，配置文件（application.yml）里需要这样写：
spring: datasource:
dynamic:
datasources:
master: # 主库（写）
url: jdbc:mysql://master:3306/main_db
username: root
password: 123456
slave1: # 从库1（读）
url: jdbc:mysql://slave1:3306/main_db
username: root
password: 123456
tenant_001: # 租户001独立库
url: jdbc:mysql://tenant001:3306/tenant_001_db
username: tenant001
password: 654321
这里要注意：3.2的DynamicDataSource工厂类不再自动注入所有数据源，需要手动通过@Configuration注册，避免未使用的数据源被错误加载。
最关键的是实现AbstractRoutingDataSource的子类，重写determineCurrentLookupKey()方法。但3.2对AbstractRoutingDataSource的线程上下文管理做了优化，之前用ThreadLocal可能导致的内存泄漏问题，现在通过ConcurrentHashMap+弱引用解决了。
具体步骤：
@TargetDataSource，支持指定数据源名称（如@TargetDataSource("slave1")）； ThreadLocal中； DynamicRoutingDataSource类，重写determineCurrentLookupKey()，从ThreadLocal获取数据源名称。 举个反例：之前有同事直接在切面里用RequestContextHolder存数据源名称，结果遇到异步任务时，上下文丢失导致切换失败。3.2 用InheritableThreadLocal，确保子线程能继承父线程的数据源配置。
这是企业级应用最容易踩的坑。Spring Boot 3.2的DataSourceTransactionManager默认启用了“严格模式”，如果在事务中切换数据源，会抛出TransactionException。解决方案有两种：
| 方案 | 适用场景 | 注意事项 |
||||
| 编程式事务 | 短事务、手动控制边界 | 需手动调用begin()和commit() |
| 多事务管理器隔离 | 长事务、多数据源操作 | 需为每个数据源单独配置PlatformTransactionManager |
比如，某金融系统的对账功能需要同时操作主库和租户库，用多事务管理器方案：为master和tenant_001分别配置MasterTransactionManager和TenantTransactionManager，通过@Transactional(transactionManager = "tenantTransactionManager")指定，彻底避免事务串库。
企业级避坑：这4类问题90%的项目都遇到过
即使按步骤实现，生产环境还是可能出问题。根据近3年的项目经验， 4类高频问题及解决方案：
ThreadLocal未及时清理，比如在@Around切面里忘记执行ThreadLocal.remove()，导致下一次请求复用线程时数据源名称未更新。解决办法：在切面的finally块强制清除ThreadLocal。 @Transactional注解的方法中，先执行写操作（主库），再切换数据源执行读操作（从库），结果写操作失败时，从库的读操作不会回滚。3.2的解决方案是：在事务开始前确定数据源，或者使用@Transactional(propagation = Propagation.NESTED)嵌套事务。 HikariDataSource实例，通过spring.datasource.dynamic.hikari.maximum-pool-size分别控制连接池大小（比如主库设20，从库设10）。 DataSource默认是单例的，新增数据源需要手动调用DynamicDataSource的addDataSource()方法，并刷新ApplicationContext中的数据源Bean。 最后提醒：上线前一定要做压力测试，重点关注多线程切换时的性能损耗（3.2的优化后，切换耗时比2.x降低了约30%），以及连接池的回收策略（ 设置idleTimeout=300000，避免频繁创建连接）。
动态数据源切换到底会不会拖慢系统？这是很多人最关心的问题。其实Spring Boot 3.2已经做了针对性优化，和2.x版本比起来，切换耗时差不多降了30%。但实际用的时候，性能影响还是要看两个关键点：一个是线程上下文怎么管，另一个是连接池怎么配。
先说线程上下文这块儿，3.2对ThreadLocal的管理做了改进，用弱引用存数据，内存泄漏的风险小了很多。以前有时候切着切着，数据源信息没清干净，线程被复用的时候就容易乱套，现在这种情况少多了。
再看连接池配置，这一步特别容易被忽略。比如你要是所有数据源共用一个连接池，赶上高并发的时候，主库的连接可能被抢光，从库反而没连接可用，查询直接卡那儿。所以最好给每个数据源单独配连接池，像主库这种写操作多的，最大连接数可以设成20；从库读操作多但压力小，设10就够。 连接别一直占着不用，把idleTimeout设成300000（也就是5分钟），过了5分钟不用的连接自动回收，既保证复用又不会浪费资源。
动态数据源切换会影响系统性能吗？如何优化？
Spring Boot 3.2对动态数据源切换的性能做了针对性优化，相比2.x版本切换耗时降低约30%。但实际性能影响主要取决于两个因素：一是线程上下文的管理效率（3.2通过弱引用优化了ThreadLocal内存占用），二是连接池的配置。 为每个数据源单独设置连接池（如主库最大连接数设20，从库设10），避免资源竞争；同时设置idleTimeout=300000（5分钟），平衡连接复用与回收效率。
多租户场景下，如何避免不同租户的数据互相污染？
最核心的是确保数据源上下文的隔离性。常见问题是ThreadLocal未及时清理，导致线程复用时数据源名称未更新。解决方案：在AOP切面的finally块中强制调用ThreadLocal.remove()，彻底清除旧上下文； Spring Boot 3.2优化了AbstractRoutingDataSource的线程上下文管理，默认使用弱引用存储数据源键，进一步降低内存泄漏风险。
事务中切换数据源导致回滚失败，该怎么处理？
Spring Boot 3.2的DataSourceTransactionManager默认启用“严格模式”，事务中切换数据源可能抛异常。推荐两种方案：一是使用编程式事务（手动调用begin()和commit()），明确控制事务边界；二是为每个数据源单独配置PlatformTransactionManager，通过@Transactional(transactionManager = “xxxManager”)指定事务管理器，彻底避免跨数据源事务问题。
新增租户需要动态添加数据源时，配置不生效怎么办？
这是因为3.2的DataSource默认是单例的，新增数据源需手动触发更新。具体步骤：调用自定义DynamicDataSource类的addDataSource()方法（传入新数据源的配置参数），然后通过ApplicationContext的refresh()方法刷新Bean定义，确保新数据源被正确注册到容器中。生产环境 配合配置中心（如Nacos）实现自动化热更新。
