信创数据库适配实战：达梦、金仓、OceanBase 在可观测平台的落地差异

适配信创数据库，先认清一个前提

把可观测平台的元数据、告警规则、检索索引落到国产数据库上，不是「换个连接串」那么轻。达梦、金仓、OceanBase 三家各有各的方言和默认行为，SQL 写得越通用，踩的坑越少。这一节讲我们在三个库上跑 OBSERVE 时遇到的真实差异，按「能提前规避」和「必须现场适配」分类。

大小写敏感与标识符

这是最常见的坑，几乎每家都栽过。达梦 DM8 默认大小写敏感，建表时表名、字段名如果没加引号，会被统一转成大写；查询时 select user_id from t_user 可能因为字段实际存成 USER_ID 而报错。金仓 KingbaseES 默认兼容 Oracle 模式，行为类似。OceanBase 走 MySQL 兼容模式时大小写不敏感，行为反而接近 MySQL。

举个例子：达梦上建表 CREATE TABLE t_user(user_id INT)，字段实际存成 USER_ID；应用里写 SELECT user_id FROM t_user 会报「无效列名」。要么建表时统一大写，要么查询时给字段加双引号并保持大小写一致。

适配建议：建表脚本统一把标识符加双引号或统一大写，别指望「两边都能写」。OBSERVE 的初始化脚本已经按各库方言生成了对应版本，直接拿对应脚本执行，不要手改。

SQL 方言差异：分页、函数、类型

三家的 SQL 方言差异集中在几处：

• 分页：达梦/金仓用 LIMIT ? OFFSET ? 或 ROWNUM，OceanBase MySQL 模式用 LIMIT ?, ?。检索日志的大结果集分页是高频路径，这里写错直接导致翻页报错。以日志检索为例，达梦上翻页写 ... ORDER BY ts DESC LIMIT 100 OFFSET 200，OceanBase MySQL 模式则写 LIMIT 200, 100；
• 字符串函数：CONCAT、SUBSTR、IFNULL/NVL 三家叫法不一，达梦/金仓偏 Oracle 风格（NVL），OceanBase MySQL 模式偏 MySQL（IFNULL）；
• 时间类型：TIMESTAMP 的精度、NOW()/SYSDATE 语义有差异，日志时间戳字段要做统一映射。

我们的做法是把方言差异收敛到一层 ORM 方言适配器里，上层业务代码只写标准 SQL，由适配器翻译成各库方言。这样换库时改一处，不用全项目散改。

连接池、驱动与初始化

驱动版本是硬性要求：达梦用官方 JDBC 驱动，金仓用 KingbaseES 驱动，OceanBase 走 MySQL 协议可用 MySQL 驱动但要关掉某些 MySQL 特有选项。连接池参数也要调：国产库在高并发下的连接建立成本更高，建议把连接池最小连接数调高、空闲回收时间放宽，避免查询高峰时频繁建连拖慢检索。另外把连接串里的时区和字符集参数显式写死（serverTimezone、useUnicode=true&characterEncoding=utf8），别依赖默认值，三家默认值并不一致。

初始化脚本要覆盖建库、建表、索引、分区、初始化数据五步，并且要幂等（可重复执行）。信创环境经常是内网隔离、手工执行脚本，脚本写得越明确越好，别依赖交互式提示。

压测对比与选型建议

在相同规格（8C32G、SSD）下对三个库做了简单的写读压测，结论供参考，具体以你们自己的负载为准：

• 写入吞吐（批量 insert）：OceanBase ≈ 达梦 > 金仓；
• 范围查询/分页（日志检索典型负载）：三家差距不大，OceanBase 略优；
• 运维复杂度：达梦/金仓单机部署简单，OceanBase 分布式能力最强但运维门槛最高。

选型建议：单机房、数据量中等，选达梦或金仓省心；多机房、数据量大、要横向扩展，选 OceanBase。别因为「国产化」三个字就一定要上最复杂的方案，先想清楚数据规模和运维能力。

上线前的验收清单

换库不是切完连接串就完事，给一份验收清单：初始化脚本幂等跑三遍不报错；核心查询（日志分页、指标聚合、告警规则读取）在目标库上跑通并记录 P95 延迟；大小写、时区、字符集（UTF-8）三个配置逐项确认；备份恢复演练一次。把这条清单跑完，才算真正完成信创数据库适配。