MyBatis-Plus多数据源分页方言切换问题解析与解决方案

问题背景

在使用MyBatis-Plus（3.5.5-3.5.6版本）的多数据源功能时，开发者遇到了一个典型的分页方言切换问题。具体表现为：当系统同时配置MySQL和SQL Server数据源时，首次访问某个数据源的分页查询正常，但切换数据源后分页功能会出现异常。

问题现象深度分析

通过调试发现，问题核心在于PaginationInnerInterceptor拦截器中的方言获取逻辑。具体表现为：

1. 首次分页查询：dialect为空，系统能正确识别当前数据源类型并设置对应方言
2. 后续查询：dialect保留了上一次查询的方言值，而dbType为空，导致无法重新识别新的数据源类型

这种缓存机制在多数据源环境下会导致方言切换失效，特别是当交替使用不同数据库类型（如MySQL和SQL Server）时尤为明显。

技术原理剖析

MyBatis-Plus的分页功能通过PaginationInnerInterceptor实现，其核心工作流程包含：

1. 拦截Executor的query方法
2. 通过findIDialect方法获取当前数据库方言
3. 根据方言生成特定数据库的分页SQL

在3.5.x版本中，方言获取逻辑存在以下特点：

• 使用类变量缓存已获取的方言实例
• 依赖JdbcUtils.getDbType识别数据库类型
• 多数据源切换时缺乏方言重置机制

解决方案

针对该问题，推荐以下几种解决方案：

方案一：使用无参构造器

new PaginationInnerInterceptor()

这种方式会强制每次分页时重新获取方言，但可能带来轻微性能损耗。

方案二：自定义方言获取逻辑

通过继承PaginationInnerInterceptor并重写findIDialect方法：

public class DynamicPaginationInterceptor extends PaginationInnerInterceptor {
    @Override
    protected IDialect findIDialect(Executor executor) {
        // 自定义方言获取逻辑，确保每次都能获取正确的方言
        return super.findIDialect(executor);
    }
}

方案三：版本回退

确认3.3.2版本无此问题，如需快速解决可暂时回退版本。

最佳实践建议

对于多数据源项目，建议：

1. 为每个数据源配置独立的PaginationInnerInterceptor实例
2. 在数据源切换时主动重置分页拦截器状态
3. 考虑使用@Scope(value = "request")确保拦截器实例不共享

总结