开源如何适配国产数据库？

本文目录导读：

1. 第一阶段：评估与规划（先别急着改代码）
2. 第二阶段：核心适配工作（动手改）
3. 第三阶段：测试与调优
4. 第四阶段：长期维护
5. 现实避坑经验（价值千金）
6. 总结：适配路线图（建议）

这是一个非常务实且具有前瞻性的问题,随着国产数据库（如TiDB、OceanBase、GaussDB、达梦DM、人大金仓KingbaseES、南大通用GBase等）在信创和云原生场景中的普及，将开源软件（如WordPress、Discourse、GitLab、各种CMS和ERP系统）适配到这些数据库上，已成为刚需。

适配的难度主要取决于开源软件对数据库的依赖深度，如果只用到标准的SQL和ORM（对象关系映射），适配工作量很小；如果用了大量数据库特有的方言、存储过程、扩展，则需要更多改造。

以下是系统性的适配步骤和策略：

第一阶段：评估与规划（先别急着改代码）

1. 确认目标数据库的兼容性层级：

   • MySQL兼容模式： TiDB、OceanBase、PolarDB等原生或高度兼容MySQL协议，这类适配最简单，通常只需更换驱动（JDBC/ODBC）并微调SQL。
   • Oracle兼容模式： OceanBase、达梦、GaussDB等支持Oracle语法，适配重点是去除Oracle特有的语法（如CONNECT BY）或使用其兼容模式。
   • PostgreSQL兼容模式： GaussDB、PolarDB for PostgreSQL、TDSQL for PG等，适配相对简单，因为PostgreSQL本身就很标准。
   • 自研内核（不兼容主流）： 达梦、金仓、GBase通常属于此类，它们有自己的SQL方言，适配工作量最大。

2. 识别软件的技术栈：

   • ORM框架： 使用Hibernate、MyBatis、Sequelize、Django ORM、Prisma等？如果ORM足够成熟，通常只需更改数据库方言配置。
   • 直接SQL： 软件中是否包含大量手写的原生SQL、存储过程、触发器、视图？这是最大的工作量来源。
   • 扩展/插件： 依赖数据库特有功能的第三方插件（如WordPress的地理位置插件）需要单独适配。

3. 选择适配策略（三种路径）：

   • 完全替换（高风险，高回报）： 直接迁移数据并修改代码，适用于有专业DBA和开发团队的场景。
   • 双写/双读（渐进式，推荐）： 先让应用同时写入老数据库和国产库，读流量逐步切换，风险可控，便于回滚。
   • Proxy/中间件适配（低成本，有局限）： 在应用和数据库之间加一层SQL转换代理（如ShardingSphere、ProxySQL的自定义脚本），自动改写SQL方言，适合SQL差异不大且性能不敏感的场景。

第二阶段：核心适配工作（动手改）

数据库驱动（Driver）更换

• JDBC/ODBC： 从MySQL Connector/J 切换到 TiDB/OceanBase的JDBC驱动，或达梦专用的DM JDBC驱动。
• Python： pip install pymysql 换为 pip install pymysql（TiDB兼容）或 pip install dmPython。
• 驱动配置： 注意URL格式、时区、字符集（通常是UTF-8 vs GBK，达梦老版本默认GBK需注意）。

SQL方言适配（最繁琐的部分）

• 关键字冲突： 国产库可能保留更多关键字（如LEVEL、TYPE、USER），需用反引号或双引号转义字段名，建议全局搜索并修改或配置数据库关键字处理规则。
• 分页查询： MySQL用LIMIT... OFFSET，Oracle/达梦用ROWNUM或OFFSET FETCH，ORM框架一般能处理好，但手写SQL需逐条改。
• 函数替换（高发区）：
  • NOW() -> CURRENT_TIMESTAMP / SYSDATE
  • CONCAT() -> 或 CONCAT()（不同库不同）
  • GROUP_CONCAT() -> LISTAGG() 或 WM_CONCAT()（达梦特有）
  • UUID() -> SYS_GUID()（Oracle系）或直接调用Java/应用层生成。
• 自增列语法： MySQL的AUTO_INCREMENT -> 达梦/金仓的IDENTITY或SERIAL。
• 数据类型映射（核心痛点）：
  • TINYINT(1) -> 可能被映射为布尔型，导致存储0/1之外的值出错。
  • VARCHAR长度：MySQL的VARCHAR(65535)等效于TEXT，但达梦的VARCHAR长度上限可能不同（如32767），大文本建议显式改为TEXT或CLOB。
  • DATETIME vs TIMESTAMP：国产库对时间精度的处理可能不同（如达梦6的TIMESTAMP精度默认6位，强制指定会报错）。

ORM方言配置

• Hibernate/MyBatis： 修改配置文件中的dialect属性。
  • org.hibernate.dialect.MySQLDialect -> io.shardingsphere.transaction.base.context.TransactionalDataSource（非标准，需查找对应国产库的Dialect类，或自己编写）。
  • 关键点： 如果没有现成Dialect，需要继承Dialect类，重写getLimitString()（分页）、supportsIdentityColumns()（主键生成策略）等方法。
• 通用ORM（如Sequelize、Django ORM）： 查看是否支持目标数据库的方言包（如sequelize-oceanbase、django-gaussdb）。

存储过程与触发器（避坑指南）

• 策略： 尽量用应用层逻辑替代，存储过程是迁移的最大阻力，且国产库的存储过程语法差异巨大（例如达梦的FOR LOOP与Oracle不同，且缺少CONTINUE等关键词）。
• 如果必须保留： 使用PL/SQL（Oracle系语法）或T-SQL（SQL Server系语法）逐行调试，建议新建一个/db/migration/specific_procs.sql文件存放适配后的版本。

数据迁移与校验

• 工具：
  • 使用官方迁移工具（如TiDB的TiDB Data Migration (DM)、OceanBase的OMS）。
  • 开源ETL工具（DataX，Apache NiFi）。
• 校验： 不只是行数一致，要检查：
  • 特殊字符（emoji、中文与GBK兼容性）。
  • 时区（时间字段是否会偏移）。
  • 自增ID（主键是否冲突，如已有业务依赖ID自增顺序）。
  • 唯一索引/ 大小写敏感：MySQL默认不区分大小写（collation ci），而很多国产库（如达梦）区分大小写，需要在建表时指定COLLATE case_insensitive或兼容模式。

第三阶段：测试与调优

1. 功能测试： 覆盖增删改查、事务、隔离级别（MySQL的REPEATABLE READ与达梦的默认READ COMMITTED不同）、外键约束。
2. 性能测试：
   • 连接池： 国产库的连接池配置（如HikariCP、Druid）可能需要调整connectionTimeout、maxLifetime。
   • SQL慢日志： 开启国产库的慢查询日志，找出未走索引的SQL，国产库的优化器可能与MySQL不完全一致，需重新执行EXPLAIN。
   • 批量插入： MySQL的INSERT INTO ... VALUES (1), (2)在达梦/金仓中可能不支持或性能不佳，需改为INSERT ALL INTO ... INTO ...。
3. 回归测试： 自动化测试套件必须通过，特别关注边缘情况（如字符串0值、二进制字段、高并发下的死锁）。

第四阶段：长期维护

• 代码隔离： 在代码中尽量使用标准SQL和ORM抽象层，对于无法兼容的SQL，使用@DatabaseAnnotation或条件编译（如#if环境变量）分开维护。
• 贡献开源： 如果适配的是知名开源项目，可以考虑将适配补丁提交回上游社区（如GitHub Issue/PR），这能极大降低后续升级的维护成本。
• 文档化： 记录所有辛辛苦苦改过的适配点、已知特例（比如某国产库不支持FULL OUTER JOIN，需要用LEFT JOIN UNION RIGHT JOIN实现）。

现实避坑经验（价值千金）

1. 不要迷信“100%兼容”： 即使官方号称兼容MySQL/Oracle，在JSON操作、窗口函数细节、索引命名长度限制上仍有微妙的差异。测试环境一定建在国产库上，而不是只改驱动。
2. 达梦 & 金仓的“魔法”：
   • 达梦默认开启大小写敏感，且建表时若字段名不加双引号，会被转为大写，配置COMPATIBLE_MODE=4可模拟MySQL行为。
   • 金仓（KingbaseES）的sys_dump备份不同于MySQLmysqldump，需重新学习。
3. TiDB & OceanBase 的“陷阱”：
   • 它们虽然是分布式,但SELECT ... FOR UPDATE可能会跨节点造成延迟，需要检查应用层事务边界是否合理。
   • OceanBase的MySQL租户支持良好，但Oracle租户对PDML（并行DML）支持不完善，大量LOAD DATA会很慢。

适配路线图（建议）

如果你在架构初期： 尽量选择天生兼容MySQL/PostgreSQL的国产库（TiDB、OceanBase、PolarDB），并采用ORM抽象，避免手写SQL，兼容成本最低。

如果你已经在用特定国产库（如达梦）：

1. 短期： 使用SQL转换代理（Proxy）快速跑起来，验证功能。
2. 中期： 针对高频SQL进行手动改写，替换所有方言函数。
3. 长期： 重构ORM层，实现基于数据库类型的多方言支持（如使用Abstract Factory模式）。

一个实用的建议：一定不要试图一次性适配所有SQL，先在项目中找出所有执行慢或报错的SQL（通过开启数据库的慢查询日志和错误日志），然后逐一优化，而不是通读全部源码，这样效率最高，也最贴合实际使用场景。