KingbaseES的Oracle/PG/MySQL三种模式到底怎么选？

有个事情很多人在装KingbaseES之前没想清楚，装完之后才发现选错了——就是数据库兼容模式。

KingbaseES的兼容模式是在初始化数据库（initdb那一刻）确定的，定了就不能改。你只能在ORACLE、PG、MySQL三选一。最要命的是，不同模式下面SQL语法、函数行为、系统视图都不一样，后期切换基本等于重来。

三种模式本质上是什么

别被"兼容模式"这个名字迷惑。KingbaseES内核是基于PostgreSQL的，所谓兼容模式，本质上是在PG内核上加了一层兼容层——给SQL解析器增加了一套语法规则和函数映射。

可以这么理解：

• PG模式 —— 原生PG语法，几乎不做转换
• ORACLE模式 —— SQL进来先过一层Oracle语法转换，再交给PG内核执行
• MySQL模式 —— 同上，但换成了MySQL的语法习惯

所以性能上有细微差异是正常的，但核心引擎一样，主要区别在"语言"层面。

ORACLE模式：迁移老系统的默认选择

如果你的系统之前跑在Oracle上，没啥好犹豫的，直接选ORACLE模式。

实际迁移中省事的地方：

数据类型直接映射。 Oracle的NUMBER、VARCHAR2、CLOB、DATE（含时分秒的那种）全部能用，不用改表结构。我之前有个项目，用ORACLE模式迁移，两百多张表只改了三张——都是因为用了Oracle特有的LONG类型。

PL/SQL兼容度不错。 存储过程里的游标、异常处理、FOR循环基本都能跑。比较复杂的包（PACKAGE）大部分也可以。当然不是100%，用到Oracle19c新特性的得手动改，这就看你的代码写得有多Oracle了。

内置函数覆盖率高。 NVL、DECODE、TO_CHAR、TO_DATE、SUBSTR这些高频函数都支持。SYSDATE、ROWNUM、DUAL表也都有。

但别期待太大，有些东西ORACLE模式也做不到：

• Oracle的CONNECT BY层级查询，目前支持不完整
• MODEL子句不考虑支持
• 物化视图自动刷新的机制有差异
• 高级队列（AQ）没有

选ORACLE模式之前最好用KingbaseES自带的迁移评估工具跑一遍你的SQL，看看兼容度报告再做决定。

PG模式：新项目的最佳选择

如果是新开发的项目，之前没绑定Oracle或MySQL，我强推PG模式。

原因很简单——PG模式就是原生的PostgreSQL，没有中间层损耗，维护起来也简单。万一以后要迁到社区版PostgreSQL或者云上的RDS PG，几乎零成本。

PG模式下可以用的东西：

• 完整的PostgreSQL SQL标准支持和窗口函数
• 原生的JSON/JSONB操作
• PostGIS地理空间扩展
• 完整的FDW外部数据包装器
• PG生态的所有第三方扩展

说实话，PG模式的KingbaseES用起来就跟你熟悉的PostgreSQL一模一样，ksql的操作习惯、系统表结构、配置参数名全部沿用PG传统。

选PG模式的唯一坏处：如果你团队之前主要是Oracle或MySQL背景，需要一定的学习成本，但这个成本是值得的。

MySQL模式：适合什么场景？

MySQL模式怎么说呢——能用，但我建议除非真的必须兼容MySQL，否则别选。

适合的场景比较窄：

• 原来用MySQL的系统要往信创平台迁
• 团队只会MySQL SQL语法，其他数据库没接触过
• 用了大量MySQL特有的语法习惯（反引号、LIMIT分页等）

MySQL模式支持的东西：

• LIMIT x OFFSET y 语法
• 反引号引用标识符
• AUTO_INCREMENT 自增列
• REPLACE INTO、INSERT IGNORE 等MySQL特有语句
• show tables、show databases 等管理命令

不支持或支持不好的：

• MySQL的存储引擎概念（只有一种"引擎"，别指望InnoDB/MyISAM切换）
• ON DUPLICATE KEY UPDATE 行为不完全一致
• 一些MySQL特有的时间函数

MySQL模式的成熟度相比ORACLE和PG模式要低一些，遇到边界情况的概率更大。

模式之外的关键参数

初始化时不光要选模式，还有几个参数也影响后续使用：

大小写敏感。 这个太重要了。KingbaseES默认是大小写敏感的（跟Oracle一样），但如果你是从MySQL迁过来的，MySQL默认是不敏感的。设置成"否"之后，SELECT * FROM users和SELECT * FROM USERS效果一样。注意：一旦设定了就不能改。之前有同事因为这个参数选错，表名全部要加双引号，SQL写得痛苦无比。

字符集。 默认UTF8，一般够了。处理政务系统的老数据可能需要GBK或GB18030。注意GB18030下有些特殊字符的处理和UTF8不一样，测试要找真实数据测。

块大小。 默认8k，大多数场景够用。如果一张表的单行数据特别宽（比如存了大量VARCHAR2(4000)），考虑16k或32k能减少行溢出。

实际选型建议

你的情况	建议模式	理由
Oracle老系统迁移	ORACLE	改动最小，风险最低
全新项目	PG	生态好，灵活，未来迁移成本低
MySQL系统迁移	MySQL	语法改动少
混合型系统	PG	取最大公约数
不确定以后用什么	PG	退路最多

对了，不管你选哪种模式，最好先在开发环境上把核心SQL全部跑一遍。KingbaseES自带了迁移评估工具和SQL兼容性检测，别跳过这一步——装完之后再发现跑不通，时间成本就大了。

接上一篇文章

上篇记录了部署KingbaseES V8时内核参数、RemoveIPC和License的几个坑。模式选择是部署前就定下来的事情，下一篇准备写Docker部署方案，毕竟不是所有人都愿意在物理机或虚拟机上一步步手装。