先说一下这个标题不是我起的流行文是我实际接手的一个项目里真实遇到的问题。当时需求听起来特别简单一套Spring Boot服务接了两套数据库一套MySQL一套Oracle两边表结构基本一样但某些字段类型和SQL语法就是有差异。业务方要求尽量共用一份Mapper代码差异的地方再单独处理。一开始我下意识想的是老办法——上主流的AbstractRoutingDataSource动态切换数据源。但仔细一看这个需求路由是不变的MySQL服务固定连MySQLOracle服务固定连Oracle不存在“同一次请求里来回切换”的场景。真正要解决的是同一套Mapper在不同数据库方言下执行不同SQL的问题。这时候MyBatis自带的databaseId机制就派上用场了也就是标题里的databaseIdProvider。先说结论这套方案很轻量不用引入额外的多数据源框架也不要写拦截器纯粹靠MyBatis原生能力就能搞定。唯一要注意的是它对“多数据源”的理解和网上大多数讲动态切换数据源的文章不是一回事。这篇就把我的实操过程、配置细节和踩过的坑完整走一遍。1. 先搞清楚databaseId到底解决什么问题1.1 它和“多数据源”不是一回事很多人一听“多数据源databaseId”下意识以为是用databaseId来做数据源路由这个理解从一开始就跑偏了。MyBatis里的databaseId核心作用是在一个SqlSessionFactory内部根据当前连接的数据库类型选择执行对应的SQL语句。它是SQL级别的方言切换工具不是数据源级别的路由工具。所谓“数据源路由”解决的是“我这个请求该连A库还是B库”而databaseId解决的是“我连上库之后在MySQL里该执行哪段SQL在Oracle里又该执行哪段SQL”。这俩不是一个层面的事。如果业务场景是“根据租户ID动态切库但SQL完全一样”那该用AbstractRoutingDataSource或者shardingspheredatabaseId帮不上忙。但如果场景是“固定连接不同类型数据库SQL因方言而异”那databaseId就是最省事的方案。1.2 databaseIdProvider在中间扮演什么角色databaseIdProvider的作用只有一件从数据库连接里拿到数据库产品名然后返回一个我们自定义的标识符。MyBatis拿到这个标识符之后会把它作为databaseId参数在解析Mapper XML以及注解SQL的时候去匹配每条SQL语句上配置的databaseId属性。所以它的本质就是一套“探测-映射”机制数据库连接 - DatabaseMetaData.getDatabaseProductName() - 字符串 - databaseIdProvider映射 - 自定义databaseId比如MySQL驱动返回的产品名是“MySQL”Oracle驱动返回的是“Oracle”。默认情况下MyBatis的VendorDatabaseIdProvider会把它们转成小写于是你得到的就是“mysql”和“oracle”。我在项目里就用这两个值作为databaseId。1.3 什么时候才值得用它用不用databaseId我的判断标准很简单只有一个SqlSessionFactory但连接的数据库可能是不同类型 —— 用它很合适。有多个SqlSessionFactory每个管理一个独立数据源 —— 可用来配合方言切换但前提是每个SqlSessionFactory都配了各自的databaseIdProvider。多个数据源、SQL一样、只是需要路由 —— 不该用它那是另一套东西。多个数据源、SQL完全不同、连表结构都不一样 —— 更不该用它按数据源拆Mapper更清晰。我的场景就属于中间那种两个SqlSessionFactory各自连不同数据库一部分Mapper完全共用另一部分需要方言差异。所以方案就定型了多数据源配置 每个SqlSessionFactory绑定各自的databaseIdProvider Mapper里按databaseId写差异化SQL。2. 环境准备与多数据源基础配置2.1 依赖选型这一步很关键直接决定后面省不省事。先给出完整的Maven依赖清单parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdcom.oracle.database.jdbc/groupId artifactIdojdbc8/artifactId version21.9.0.0/version /dependency /dependencies要特别说一下版本选择。网上很多老教程还在用Spring Boot 2.3以下的版本配合mybatis-spring-boot-starter 2.1.x但实际2024年之后新项目基本都是2.7或3.x起跳。Spring Boot版本升级到2.7以后多数据源自动配置的参数绑定逻辑有变化如果不显式声明数据源和SqlSessionFactory很容易出现“明明配置了多数据源但只生效了一个”的诡异问题。另外很多人问为什么不用MyBatis-Plus或者dynamic-datasource-spring-boot-starter。我的回答是这场景不需要。dynamic-datasource解决的是动态路由问题我这里路由是固定的引入它反而多一层抽象还多一个和自己SQL配置打架的可能性。MyBatis原生能力已经够用没必要为了“省事”加一个带着自己一套规则的框架。2.2 数据源配置项对应在application.yml里我习惯用一组前缀区分两个数据源spring: datasource: mysql: driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/biz_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root123 oracle: driver-class-name: oracle.jdbc.OracleDriver jdbc-url: jdbc:oracle:thin://localhost:1521/ORCLPDB1 username: biz_user password: biz_pass注意这里用的是jdbc-url而不是url因为Spring Boot的多数据源手动配置场景下spring.datasource.url会自动绑定到主数据源上如果自定义配置还写url有可能会被自动配置干扰。这个坑我踩过一次后面排查章节会细说。2.3 配置两个SqlSessionFactory这个步骤是整个方案的核心骨架。由于我们不再依赖Spring Boot的自动配置需要手动声明两组Bean每组包含DataSource、SqlSessionFactory、Mapper扫描三个Bean。Configuration public class MybatisDataSourceConfig { Bean(name mysqlDataSource) ConfigurationProperties(prefix spring.datasource.mysql) public DataSource mysqlDataSource() { return DataSourceBuilder.create().build(); } Bean(name oracleDataSource) ConfigurationProperties(prefix spring.datasource.oracle) public DataSource oracleDataSource() { return DataSourceBuilder.create().build(); } Bean(name mysqlSqlSessionFactory) public SqlSessionFactory mysqlSqlSessionFactory(Qualifier(mysqlDataSource) DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); factoryBean.setVfs(SpringBootVFS.class); // 关键点设置databaseIdProvider factoryBean.setDatabaseIdProvider(databaseIdProvider()); // 公共Mapper XML位置 factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath:mapper/*.xml)); org.apache.ibatis.session.Configuration config new org.apache.ibatis.session.Configuration(); config.setMapUnderscoreToCamelCase(true); factoryBean.setConfiguration(config); return factoryBean.getObject(); } Bean(name oracleSqlSessionFactory) public SqlSessionFactory oracleSqlSessionFactory(Qualifier(oracleDataSource) DataSource dataSource) throws Exception { SqlSessionFactoryBean factoryBean new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); factoryBean.setVfs(SpringBootVFS.class); factoryBean.setDatabaseIdProvider(databaseIdProvider()); factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath:mapper/*.xml)); org.apache.ibatis.session.Configuration config new org.apache.ibatis.session.Configuration(); config.setMapUnderscoreToCamelCase(true); factoryBean.setConfiguration(config); return factoryBean.getObject(); } Bean(name databaseIdProvider) public DatabaseIdProvider databaseIdProvider() { VendorDatabaseIdProvider provider new VendorDatabaseIdProvider(); Properties properties new Properties(); properties.setProperty(MySQL, mysql); properties.setProperty(Oracle, oracle); provider.setProperties(properties); return provider; } Bean(name mysqlSqlSessionTemplate) public SqlSessionTemplate mysqlSqlSessionTemplate(Qualifier(mysqlSqlSessionFactory) SqlSessionFactory sqlSessionFactory) { return new SqlSessionTemplate(sqlSessionFactory); } Bean(name oracleSqlSessionTemplate) public SqlSessionTemplate oracleSqlSessionTemplate(Qualifier(oracleSqlSessionFactory) SqlSessionFactory sqlSessionFactory) { return new SqlSessionTemplate(sqlSessionFactory); } }然后Mapper扫描我按包名区分两组Mapper接口各自绑定到不同的SqlSessionFactoryConfiguration MapperScan(basePackages com.example.mapper.mysql, sqlSessionFactoryRef mysqlSqlSessionFactory, sqlSessionTemplateRef mysqlSqlSessionTemplate) public class MysqlMapperScanConfig { } Configuration MapperScan(basePackages com.example.mapper.oracle, sqlSessionFactoryRef oracleSqlSessionFactory, sqlSessionTemplateRef oracleSqlSessionTemplate) public class OracleMapperScanConfig { }之所以按包分Mapper接口而不是同一个Mapper同时注册到两个Factory主要是为了避免同名Statement冲突。MyBatis中MappedStatement的key是namespace.id如果同一个Mapper接口同时注册到两个Factory各自命名空间相同容易出幺蛾子。按包拆开同一个Factory里每个Mapper都是唯一id就稳了。3. databaseIdProvider的运作原理与自定义思路3.1 默认的VendorDatabaseIdProvider做了什么MyBatis自带的VendorDatabaseIdProvider是DatabaseIdProvider接口的默认实现逻辑非常简洁从Connection.getMetaData().getDatabaseProductName()拿到数据库产品名。先尝试直接以原产品名为key查找映射。找不到就转小写再查。再找不到就截取第一个空格之前的单词再查比如“Oracle JDBC Driver”会变成“Oracle”。默认情况下这个Provider内置了一些常见数据库的映射比如MySQL、Oracle、SQL Server、PostgreSQL、DB2等。所以如果你不显式设置PropertiesMySQL会返回“mysql”Oracle会返回“oracle”正好够用。那为什么还要显式设置原因很简单不显式设置万一某个驱动返回的产品名不是标准名称或者将来要接一个奇怪的数据库中间件默认映射就可能失效。显式设置相当于自己掌握主动权生产成本很低收益很明确——排除隐患。3.2 如果想自定义Provider怎么办看看接口就知道自己实现非常简单public class CustomDatabaseIdProvider implements DatabaseIdProvider { private MapString, String mappings; Override public void setProperties(Properties p) { mappings new HashMap(); for (String key : p.stringPropertyNames()) { mappings.put(key.toLowerCase(), p.getProperty(key)); } } Override public String getDatabaseId(DataSource dataSource) throws SQLException { try (Connection conn dataSource.getConnection()) { String productName conn.getMetaData().getDatabaseProductName(); return mappings.get(productName.toLowerCase()); } } }这个确实不难但我在项目里没有自己写原因很现实VendorDatabaseIdProvider已经足够成熟健壮。它处理了大小写和截断逻辑自己写的容易漏边界。真到要自定义Provider的时候一般是想从URL里解析库名做区分那属于另一个需求维度和databaseId的定位已经偏离了。所以我的建议是能用默认就别自定义省钱省心。3.3 databaseId是如何一路传到SQL解析的这一步要看源码不然遇到问题的时候只会瞎猜。在SqlSessionFactoryBean里buildSqlSessionFactory()方法会调用databaseIdProvider.getDatabaseId(dataSource)然后把返回值赋值给targetConfiguration.setDatabaseId(databaseId)。这时候Configuration里就有了一个全局databaseId。接下来解析Mapper XML时每个语句节点都会被拿出来和这个全局databaseId比对。具体比对逻辑在XMLStatementBuilder.parseStatementNode()里它先解析节点的databaseId属性然后调用databaseIdMatchesCurrent()判断是否匹配。判断规则的伪代码是当前语句databaseId 节点上配置的databaseId 全局databaseId Configuration里设置的databaseId 如果全局databaseId为null 只加载没有配置databaseId的语句 如果全局databaseId不为null 只加载databaseId等于全局databaseId的语句 或者没有配置databaseId的语句也就是说一旦Configuration里有了databaseId非null那么带有其他databaseId的SQL语句就会被直接跳过不注册到MappedStatement集合中。这里正好有一条软柿子可以捏同一个Mapper XML里可以同时存在不带databaseId的基础SQL和带databaseId的方言SQL它们会共存。不带databaseId的语句永远会被加载而带databaseId的语句只会在匹配当前连接类型时加载。如果方言SQL和通用SQL的statement id相同后者会覆盖前者这同时也是设计上的一个隐患——名字别乱重复。第四条直接用同一个连接执行两条预编译语句Repository public class MysqlBizDao { private final JdbcTemplate jdbcTemplate; public MysqlBizDao(Qualifier(mysqlJdbcTemplate) JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } public BigDecimal queryBizAmount() { return jdbcTemplate.queryForObject(SELECT biz_type, SUM(biz_amount) FROM biz_order GROUP BY biz_type, (rs, rowNum) - rs.getBigDecimal(biz_amount)); } }结果第一条正常返回。预编译语句缓存不吃索引这是SQL引擎的基本能力。第二条正常返回但执行计划里能看到动态采样和全表扫描的可能性因为*展开后的列在UNION场景下会产生临时排序。第三条正常返回但查询效率取决于EXTRACT函数是否命中基于函数索引基本不会命中因为EXTRACT不可逆。第四条编译错误JdbcTemplate的queryForObject结果集不是期望的单行单列因为这条SQL本身返回多行。所以说这里一条数据库方言特性都没涉及到问题全部出在SQL语义和结果集映射上。这种场景常规优化怎么做最简单有效的方法就是把需要方言支持的函数抽离出来做成CASE WHEN分支或者绑定变量。下面给一个处理“把create_time里的小时数取出来”的经典写法-- 通用版两个数据库都认 SELECT biz_type, CASE WHEN EXTRACT(HOUR FROM create_time) BETWEEN 10 AND 18 THEN day ELSE night END AS period, COUNT(*) AS cnt FROM biz_order GROUP BY biz_type, CASE WHEN EXTRACT(HOUR FROM create_time) BETWEEN 10 AND 18 THEN day ELSE night END;注意GROUP BY里必须重复一遍CASE表达式不然MySQL里能跑Oracle里会报“不是GROUP BY表达式”。这个写法规规矩矩两个库都能执行但性能一般。如果对性能有要求SQL就该拆成两段每段针对方言优化然后在DAO层做分支选择。但这样又回到老问题代码里写分支判断维护成本上来了。而这恰恰是databaseId能优雅解决的场景。所以接下来看看在Mapper里到底怎么写。4. Mapper XML与注解SQL的databaseId写法4.1 XML里怎么指定databaseIdXML语句上直接加一个databaseId属性就行。我们用实际例子说话比如从订单表里查询某段时间的汇总金额和单数select idsumOrder resultTypejava.util.Map SELECT SUM(order_amount) AS totalAmount, COUNT(*) AS totalCount FROM biz_order WHERE order_time gt; #{startTime} /select select idsumOrder databaseIdmysql resultTypejava.util.Map SELECT IFNULL(SUM(order_amount), 0) AS totalAmount, COUNT(*) AS totalCount FROM biz_order WHERE order_time gt; #{startTime} /select select idsumOrder databaseIdoracle resultTypejava.util.Map SELECT NVL(SUM(order_amount), 0) AS totalAmount, COUNT(*) AS totalCount FROM biz_order WHERE order_time gt; #{startTime} /select三条SQL的statement id都是com.example.mapper.CommonOrderMapper.sumOrder但因为databaseId不同最终同一个SqlSessionFactory里会根据连接类型只保留两条通用SQL 匹配当前databaseId的那条方言SQL。假设当前连接是MySQL最终注册的MappedStatement情况是通用版sumOrder被加载。databaseIdmysql的sumOrder被加载并且覆盖同名的通用版。databaseIdoracle的sumOrder被跳过。关键点在于“覆盖”。MyBatis注册Mapper语句时用的是基于id的Map后面注册的会覆盖前面的。由于XMLStatementBuilder解析语句时预编译的select语句会先put到configuration的mappedStatements然后方言SQL再put所以方言SQL会覆盖通用SQL。这其实就是我们的最终目标无需改DAO代码Mapper接口还是ListMapString, Object sumOrder(MapString, Object params);但执行的SQL已经根据数据库自动切换了。4.2 注解SQL也能配databaseId吗能。避免有些人习惯把简单SQL写在注解里这里给一个对照写法public interface CommonOrderMapper { Select(SELECT COUNT(*) FROM biz_order) long countAll(); Select(SELECT COUNT(*) FROM biz_order) Options(databaseId mysql) long countAllMysql(); Select(SELECT COUNT(*) FROM biz_order) Options(databaseId oracle) long countAllOracle(); }但说实话我不推荐在注解里大量这么干。原因有三个Options(databaseId...)只能指定方法级databaseId没法像XML那样把同一方法名配三种SQL必须拆方法接口会变得很臃肿。注解SQL的量一多可读性急剧下降而且因为覆盖规则IDE里看不出最终执行的是哪条。MyBatis对注解SQL的databaseId匹配也是基于Configuration里设置的databaseId匹配规则和XML一致但source层面很难直观看到。所以我的建议是XML优先注解少用。所有需要方言差异的SQL都收敛到XML里一个Mapper接口方法对应多段XML表述清晰排查方便。4.3 同一条SQL如何同时兼容多个数据库有一种常见诉求是两个数据库语法差异不大只是个别函数不一样不想为每段SQL都写两遍能不能尽量写少一点这时候可以利用一个特点通用条目不写databaseId它永远生效方言条目只在匹配时才覆盖。所以策略是大多数语句只写一个通用版本不带databaseId。只有出现函数差异或者语法差异的语句才额外写方言版本。比如select idlistRecentOrders resultTypecom.example.entity.OrderEntity SELECT id, order_no, order_time FROM biz_order WHERE order_time gt; #{startTime} ORDER BY order_time DESC LIMIT 100 /select select idlistRecentOrders databaseIdoracle resultTypecom.example.entity.OrderEntity SELECT id, order_no, order_time FROM biz_order WHERE order_time gt; #{startTime} ORDER BY order_time DESC FETCH FIRST 100 ROWS ONLY /selectMySQL下直接用LIMIT版本Oracle下用FETCH FIRST 100 ROWS ONLY版本。这种写法广西覆盖得很干净但有一个潜在风险如果将来加入第三类数据库而你想让它默认走MySQL的LIMIT语法那这个通用版SQL会被PostgreSQL之类的数据库识别不兼容。所以通用版SQL要保守确保对当前支持的所有数据库方言都有效。如果无法保证那就干脆每条SQL都带上databaseId。4.4 databaseId匹配优先级和容易混淆的行为做个简单的对照表方便理解规则Configuration里的databaseIdSQL语句上的databaseId是否加载无null无是无nullmysql否mysql无是mysqlmysql是且覆盖同名无databaseId的语句mysqloracle否这张表建议收藏排查问题的时候对着看能少掉好多头发。我第一次遇到“为什么我在Oracle库里执行了MySQL逻辑”的问题时就是一时忘了这个匹配规则排查了整整一晚上。5. 实操过程中的常见问题与排查方法5.1 配置了databaseIdProvider但SQL没切换这是我遇到最多的一类问题。症状是配置都写了项目启动也不报错但到Oracle库上执行时MySQL版本的SQL还是被调起来直接语法报错。排查顺序我建议是这样第一步确认SqlSessionFactory是否真的配置了databaseIdProvider。检查方式很简单给mysqlSqlSessionFactory打断点看返回对象的configuration.databaseId字段是不是有值。如果这个字段是null说明整个databaseId机制压根就没生效。第二步确认Mapper XML里的语句是否真的带上了databaseId属性。可以启动后直接去看XmlConfigBuilder解析过的MappedStatement里sqlSource对应的boundSql内容。如果最终执行的还是不带databaseId的版本那大概率是XML里的databaseId写错了大小写不一致或者引号漏了。第三步确认是不是多个Xml文件在同一个Factory里重复注册了。假如你的Mapper XML同时被classpath:mapper/*.xml和classpath:mapper/**/*.xml扫描到同一个文件会被解析两遍此时XMLStatementBuilder会因为id重复而抛异常或者由于某些版本容错机制导致后半部分没解析。扫描路径尽量精确factoryBean.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath:mapper/common/*.xml));第四步检查是否覆盖扫描路径。比如idea里target目录没刷新导致旧XML还在target里新XML没进去实际用的不是你以为的那份XML。这问题虽然低级但真实发生频率不低尤其是多人协作时。5.2 Spring Boot版本太高自动配置各种失效网上很多教程基于Spring Boot 2.0/2.1里面大量用了spring.datasource.url和spring.datasource.username这种写法。但Spring Boot 2.7之后特别是Spring Boot 3.x多数据源场景下手动声明DataSource和SqlSessionFactory时必须注意以下两点DataSourceBuilder创建的数据源类型默认是HikariCP如果用到其他连接池比如Druid必须显式指定类型否则可能拿到一个不知道该绑定什么URL的DataSource。Spring Boot 3.x把javax包换成了jakarta如果项目里依赖的第三方库还停留在javax时代会直接启动失败。这个问题和databaseId没关系但会导致你把大量时间花在排查环境上而不是业务代码上。另外Spring Boot 3.x配合mybatis-spring-boot-starter时记得用2.3.x以上版本否则会出现Mapper扫描不到的问题。这些细节说多了都是泪我当时就因为版本组合不熟悉在一个新项目上白白花了一个下午。5.3 MyBatis缓存导致改了SQL不生效还有一个非常隐蔽的坑就是MyBatis的本地缓存。MyBatis的一级缓存是SqlSession级别的默认开启。如果你在一个事务里先执行了某个查询然后修改了对应Mapper XML的SQL但SqlSession还是同一个那第二次执行时可能会直接命中缓存绕过了新SQL的解析和编译。这就是为什么有些人改了XML重启项目后还是老结果——其实不是XML没生效而是缓存没清。解决办法排查问题时尽量把localCacheScope设为STATEMENT绕开一级缓存干扰。如果是二级缓存检查Mapper里是否加了cache/加了的话记得在开发环境关掉。不建议在配置里全局关闭缓存而是用Options(flushCache Options.FlushCachePolicy.TRUE)或者xml里的flushCachetrue做局部控制。把这个坑单独写出来是因为“SQL不切换”这个症状和缓存问题太像了容易排查方向跑偏。5.4 多数据源事务以及和databaseId的关系还有一个经典话题多数据源下事务怎么处理尤其是Spring的Transactional默认只绑定在主数据源的事务管理器上。我们这个项目由于是两个独立的业务服务各自连接唯一的数据源所以事务问题不突出。但如果确实有跨数据源写操作的场景方案大致这么几种用Transactional(transactionManager mysqlTransactionManager)指定事务管理器。引入ChainedTransactionManager或Atomikos做分布式事务。业务上避免跨库事务用最终一致性方案。其中分布式事务的成本很高能用业务拆分解决的绝不硬上。这点真的建议项目一开始就定好原则否则后面重构很痛苦。5.5 面试常见的几个追问这个方案如果在面试中被问到大概率会追问下面几个点其实也是在考察源码理解深度第一VendorDatabaseIdProvider的加载顺序是什么样的答案我刚才提过先进DatabaseMetaData拉产品名然后按“原始名-小写-空格截断”三步查找。如果想知道细节可以自己翻一下源码其实不到100行。第二Mapper语句加载时databaseId不匹配到底是怎么跳过的这个对应XMLStatementBuilder里的databaseIdMatchesCurrent方法本质就是比较configuration.getDatabaseId()和当前语句的databaseId规则跟着全局databaseId是否为null走。第三databaseId能不能用来做读写分离这是一个常见的误区。读写分离的目标是根据操作类型路由而不是根据方言路由两者维度不同。如果非要用databaseId硬做基本是缘木求鱼建议直接上shardingsphere或者手写拦截器。6. 这套方案的适用边界与扩展思路6.1 什么时候该放弃databaseId虽然文章一直在给这个方案说好话但也要冷静地提一下它的边界。如果表结构差异极大比如MySQL和Oracle里的表名、字段名完全不同连实体类都没法共用那就没必要用databaseId硬凑了。老老实实拆两个独立的Mapper包、两个独立的实体包甚至拆成两个微服务都更清晰。如果需求的本质是“同一套逻辑在不同库里执行不同SQL”而且这种差异出现在几十个查询上那databaseId反而会让Mapper XML变得特别臃肿。每条SQL都要写两遍甚至更多维护成本不低。这时候我会建议结合MyBatis的拦截器做一些自动化的SQL改写把方言差异收敛到一处。不过话又说回来大多数真实项目的方言差异也就是分页、空值函数、时间函数这几类。用databaseId把这些点挨个覆盖掉是完全可控的。6.2 是否还能玩出更多花样除了最基本的“不同数据库跑不同SQL”databaseId还有几个衍生玩法我简单提一下一是可以将databaseId作为Mapper加载时的过滤条件结合Spring的Profile做多环境切换。比如本地开发用H2测试环境用MySQL生产用Oracle同一份代码配合databaseIdProvider就能自动适配不用改配置。这个真的是日常开发的大杀器很多人没意识到。二是可以结合MyBatis的拦截器在Executor层拿到MappedStatement和databaseId做一些通用的逻辑处理比如自动填充创建人、修改人等审计字段时根据databaseId选择不同的序列生成策略。这算锦上添花但也足够实用。三是可以用databaseId给不同数据库设置不同的批量提交策略。Oracle的批量插入和MySQL的批量插入在ExecutorType.BATCH模式下有一些差异用databaseId做分支判断可以精准控制。6.3 一个完整的伪代码流程再串一遍整个流程让模式清晰起来// 启动时 // 1. Spring容器创建mysqlDataSource、oracleDataSource // 2. 每个SqlSessionFactory创建时先通过databaseIdProvider探测当前数据源的databaseId // 3. 探测结果注入到org.apache.ibatis.session.Configuration.databaseId // 4. Mapper扫描时XMLStatementBuilder逐个解析Mapper XML中的语句 // 5. 每个语句通过databaseIdMatchesCurrent判断是否与当前databaseId匹配 // 6. 匹配的语句注册到MappedStatement集合不匹配的跳过 // 运行时 // 1. 调用Mapper接口方法 // 2. MapperProxy找到对应的MappedStatement // 3. 执行SQL因为MappedStatement已经是方言匹配后的版本所以SQL天然正确这套流程清晰之后你会发现databaseId其实是一个非常轻量但很本质的机制它的存在让MyBatis在同一个SqlSessionFactory内部就有能力感知“我在和哪个数据库说话”。7. 踩过几次坑之后的个人心得先说说我对databaseId最大的感受吧。它不像主从分离那么花哨不像分库分表那么复杂但它在“方言兼容”这个细分场景下的作用是很多中间件替代不了的。它让我在维护两个数据库时不用维护两套Mapper接口和两套Service代码只需要在需要的SQL旁边多写一份方言版本即可代码量省了大概三分之一。第二点心得是关于“多数据源”这个词的。很多人一听到多数据源就想到动态切换、读写分离、分布式事务。但实际项目里的多数据源很多时候就是这么简单不同模块连接不同的库互相之间不来回切换甚至彼此老死不相往来。对这种场景真的不需要重量级框架Spring Boot原生多数据源配置 MyBatis的databaseId机制就已经能给出一套清爽的解决方案。最后再分享一个小技巧。在配置databaseIdProvider的时候建议给每个数据库的映射值起一个比较有业务含义的名字比如不只是“mysql”和“oracle”也可以用“online”和“archive”。这样如果将来某个库从Oracle迁移到PostgreSQL只需改一个映射值所有Mapper里配置为“archive”的SQL语句依然指向正确的方言版本。这个命名上的小设计省得以后大面积改XML。文章到这基本就讲完了。按照惯例我也说说这个方案的实际运行情况目前在生产环境跑了大半年两个数据库各承担不同的业务模块共用同一套Controller和Service只在Mapper层做了方言隔离整体维持稳定。如果你正被一类“同一套服务兼容两套数据库”的需求折磨不妨试试这条路。