MyBatis-Flex多数据源配置在1.9.0版本中的关键变更解析

MyBatis-Flex作为一款优秀的ORM框架，在多数据源支持方面一直表现突出。然而在1.9.0版本升级中，其多数据源获取机制发生了重要变化，这可能会影响部分升级用户的业务逻辑。本文将深入分析这一变更的技术细节。

多数据源获取机制的演进

在1.8.9版本中，MyBatis-Flex通过MapperInvocationHandler类实现InvocationHandler接口来处理数据源路由。其核心逻辑是在getConfigDataSourceKey方法中直接根据UseDataSource注解或实体类的dataSource属性动态确定数据源。这种方式简单直接，每次方法调用都会重新计算数据源。

而1.9.0版本引入了FlexMapperProxy类，它继承自MybatisMapperProxy，同样在getConfigDataSourceKey方法中实现数据源路由逻辑。但关键区别在于新增了methodDsKeyCache这个Map结构，用于缓存Method对象与数据源键的映射关系。

缓存机制带来的行为变化

1.9.0版本引入的methodDsKeyCache带来了性能优化，但也改变了多数据源的行为特性：

1. 首次调用：当某个Mapper方法第一次被调用时，框架会通过UseDataSource注解或实体数据源配置确定数据源，并将此映射关系缓存。

2. 后续调用：同一方法的后续调用将直接从缓存中获取数据源键，不再重新计算。这意味着即使底层实体数据源发生变化，框架仍会使用缓存的数据源。

实际影响场景

这种变更在以下场景会产生明显影响：

1. 动态数据源切换：如果业务中依赖实体对象的dataSource属性动态切换数据源，在1.8.9中可以正常工作，但在1.9.0中由于缓存机制，后续调用可能无法感知数据源变化。

2. 多租户场景：在基于不同租户动态分配数据源的系统中，缓存可能导致租户数据源切换失效。

3. AOP代理场景：某些通过AOP动态修改数据源的实现可能因缓存机制而失效。

解决方案与最佳实践

对于需要升级到1.9.0版本的用户，建议：

1. 显式声明数据源：尽可能在Mapper方法上使用@UseDataSource注解明确指定数据源，而非依赖动态计算。

2. 禁用方法缓存：对于确实需要动态数据源的场景，可以考虑扩展FlexMapperProxy并重写相关逻辑。

3. 统一数据源策略：评估业务是否真的需要方法级别的动态数据源切换，或许可以在更高层级（如Service层）确定数据源。

框架设计思考

这一变更反映了框架在性能与灵活性之间的权衡。缓存机制显著提升了频繁调用场景下的性能，但牺牲了部分动态灵活性。作为使用者，理解这一设计取舍有助于我们更好地使用框架特性。

MyBatis-Flex团队已在后续版本中修复了这一问题，建议受影响的用户关注官方更新。同时，这也提醒我们在框架升级时需要仔细阅读变更日志，特别是涉及核心机制的变化。