对于新系统我们可以参考mybatis-flex，现实中我们都是对已有系统进行数据库信创改造或替换，所以如何为系统改造选择XML编写方案，才是常见的场景。通常的建议和最佳实践是：为不同的数据库编写独立的、分开的 XML 文件。
下面我将详细解释为什么这么做，以及两种方式的优缺点和适用场景。
方案一：多套 XML 分开写（推荐）
这种方式为每个需要兼容的数据库（如 MySQL、Oracle、PostgreSQL）创建一个独立的 XML 映射文件。
示例结构：
src/main/resources/mapper/
├── UserMapper.xml # 公共基础映射（如果有，可选）
├── mysql/
│ └── UserMapper.xml # 包含MySQL方言的SQL
├── oracle/
│ └── UserMapper.xml # 包含Oracle方言的SQL
└── postgresql/
└── UserMapper.xml # 包含PostgreSQL方言的SQL
优点：
- 清晰度高，易于维护：每个文件只关注一种数据库的语法，结构非常清晰。当需要修改某个数据库的SQL时，不会影响到其他数据库。
- 可读性强：开发者可以很容易地找到特定数据库的SQL实现，没有大量的条件判断干扰。
- 避免条件爆炸：对于复杂的SQL语句，如果所有兼容逻辑都写在一个文件里，会变得异常臃肿和复杂（
if...elseif...elseif链）。 - 性能更优：在应用启动时，MyBatis 只需要加载与当前配置数据库相关的XML文件，解析速度更快，内存占用更少。
- 与数据库方言深度集成：可以方便地使用各数据库独有的特性（如
ON DUPLICATE KEY UPDATE/MERGE INTO/RETURNING等），而不需要在同一文件里用大量<if>标签来判断。
缺点：
- 文件数量增多：如果有 N 个Mapper和 M 种数据库，最多会有 N*M 个文件。但可以通过合理的包结构进行管理。
- 可能存在重复代码：不同数据库的SQL语句如果完全相同，也需要在每个文件中写一遍。但通常可以通过继承、引用或代码生成器来缓解。
如何实现？
在 MyBatis 配置中，根据不同的环境（环境变量、配置参数）来设置不同的 mapper-locations 即可。
# application.yml (Spring Boot 示例)
mybatis:
mapper-locations: classpath:mapper/${db.dialect}/*.xml
这里的 db.dialect 是一个自定义配置项，可以在应用启动时设置为 mysql, oracle 或 postgresql。
方案二：在一套 XML 中兼容
这种方式将所有数据库的SQL都写在一个XML文件中，使用 MyBatis 的动态SQL标签（如 <if>、<choose>）来区分不同的数据库。
示例：
<insert id="insertUser" parameterType="User">
INSERT INTO user (
name, age
<if test="_databaseId == 'oracle'">
,create_time
</if>
) VALUES (
#{name}, #{age}
<if test="_databaseId == 'oracle'">
,SYSDATE
</if>
)
<selectKey keyProperty="id" resultType="long" order="AFTER">
<choose>
<when test="_databaseId == 'mysql'">
SELECT LAST_INSERT_ID()
</when>
<when test="_databaseId == 'oracle'">
SELECT SEQ_USER.CURRVAL FROM DUAL
</when>
<when test="_databaseId == 'postgresql'">
SELECT CURRVAL('seq_user')
</when>
</choose>
</selectKey>
</insert>
优点：
- 所有逻辑集中在一处：理论上，一个SQL的所有变体都在同一个地方，可以看到全貌。
- 文件数量少：只有 N 个Mapper文件。
缺点：
- 维护地狱：对于复杂的SQL，文件会变得极其臃肿和难以阅读，可维护性急剧下降。
- 容易出错：修改一个数据库的SQL时，很容易误改或漏掉其他数据库的条件分支。
- 启动性能差：MyBatis 需要解析所有SQL的所有分支，即使大部分分支永远不会被执行。
- 不适合方言差异大的场景：如果不同数据库的SQL写法截然不同（例如分页查询），强行写在一起会非常别扭。
总结与建议
| 特性 | 多套 XML（分开写） | 一套 XML（内部兼容） |
|---|---|---|
| 维护性 | 高（结构清晰，隔离性好） | 低（容易互相干扰，代码臃肿） |
| 可读性 | 高（一目了然） | 低（大量条件判断干扰） |
| 性能 | 高（仅加载所需文件） | 低（解析所有代码分支） |
| 文件数量 | 多（N*M） | 少（N） |
| 适用场景 | 中大型项目，多数据库支持 | 小型项目，SQL简单，差异小 |
结论：
强烈推荐使用“多套 XML 分开写”的方式。
这在实践中被证明是更可靠、更专业、更具可扩展性的方案。虽然文件数量稍多，但通过合理的目录结构（如按数据库分目录）和配置化，完全可以管理得很好。这种方式的优点远远超过了其缺点，特别是在需要长期维护和迭代的项目中。
只有当需要兼容的数据库数量很少（比如只有2个），并且SQL语句非常简单，差异非常小时，才考虑使用一套XML内部兼容的方案。对于绝大多数严肃的商业项目，分开写是更好的选择。