1.4 选型对比：openGauss、PostgreSQL、MySQL 与商业国产库
1.4 选型对比：openGauss、PostgreSQL、MySQL 与商业国产库
本节摘要：选型不是选"最好的数据库"，是选"约束条件下犯错最少的那个"。本节把 openGauss、PostgreSQL、MySQL 与商业国产库放到许可证、兼容策略、高可用方案、典型场景、人才储备五个维度上对比，并给出可直接引用的分场景结论。
凭什么说它适合政企核心系统？
把四个候选摆上桌，第一个要问的是：你的约束是什么？受监管行业先看合规与自主可控，互联网业务先看生态与人力储备，已有 Oracle 存量先看迁移成本。约束不同，同一张对比表会读出完全不同的结论。这就是本节先给维度、再给结论的原因——维度是稳定的，结论跟着你的约束走。
图：四个候选数据库的五维对比矩阵
一张会说话的对比表
上图的矩阵适合投影到大屏，谈细节还需要文字版。三个最常被追问的差异点展开如下。
许可证与自主性。openGauss 采用木兰宽松许可证，源码完全开放且社区由中国产业界主导，在"关键信息基础设施"类项目的技术评估表里，这一项可以拿满分；MySQL 的 GPL 系许可对商业集成有额外注意义务；商业国产库则完全依赖厂商授权。
高可用的完成度。MySQL 的主从复制与组复制生态最成熟，社区文档铺天盖地；PostgreSQL 的流复制本身可靠，但故障切换需要 Patroni 之类第三方组件拼装，拼装质量取决于团队水平；openGauss 把流复制和 CM 集群管理组件做成了发行版内建物，开箱即得主备仲裁与自动切换——这是"为替代场景设计"的直接证据，第 5 章会实地拆解。
兼容策略。若存量是 Oracle，四个候选里商业国产库与 openGauss（配合兼容插件）是第一梯队，MySQL 方言差异最大。若存量是 MySQL，反而要小心：openGauss 与 MySQL 语法相似度没有想象中高，迁移工具能自动化大部分，但存储过程要人工过一遍。
完整决策案例：某制造集团 ERP 数据库替代
背景：集团 ERP 跑在老旧 Oracle 上，license 到期，管理层要求两年内完成替代，预算有限，IT 团队四十人只有三人懂 PG 系。决策过程分五步。第一步列硬约束：信创目录符合性、预算上限、不停机窗口每季度一次、现有备份体系必须兼容。第二步筛候选：商业国产库报价超预算被排除；MySQL 方言差异大且团队无 DBA 储备被降权。第三步做验证：用 ERP 的脱敏真实数据做全量迁移演练，openGauss 加 Oracle 兼容插件，三千个对象里约百分之九直接通过，存储过程改造工作量折算约六人月，可接受。第四步压测：账务月结场景回放，同步复制下峰值 TPC 达到原系统八成，满足业务方底线。第五步定盘子：核心 ERP 用 openGauss 集中式主备，报表库用同版本单机，配套采购原厂三年支持。事后复盘，最大的意外收益是团队用 PG 系文档补齐了知识盲区——这与人才储备维度"PG 背景可平移"的判断一致。变式：如果你们的存量是 DB2 或 Sybase，同一套流程照样走，只是第二步的兼容排序要重排。
分场景速查结论
- 政企、金融、运营商的核心替代项目，预算有限又要自主可控：openGauss 首选，商业发行版做兜底服务；
- 存量 Oracle、预算充足、要求"最平滑"：商业国产库与 openGauss 并列进入 POC，用真实对象通过率说话；
- 互联网高并发、读写分离 + 分片架构、招聘优先：MySQL 仍是默认答案；
- 复杂分析、GIS、插件生态丰富度优先：PostgreSQL 及其衍生分支更顺手；
- 初创团队快速出活、运维人力为零：托管云数据库（各云厂商基于上述内核的服务）优先于自建。
评审会答辩要点：怎么回应四个必问问题
选型方案过评审会，四个问题几乎必到。问题一，"万一社区不活跃了怎么办"——回应路径是开源治理结构加多个商业发行版的共生格局：社区由中国产业界多家企业与高校共同运营，且有商业公司兜底服务，单点衰退的风险远小于单一厂商闭源产品。问题二，"出问题谁负责"——区分社区版与商业版的支持承诺，方案里写清响应时效与升级路径，评审最忌"有问题网上问"的含糊表述。问题三，"性能到底比现有系统快多少"——坚持用你们 POC 的回放数据回答，通用跑分一律注明测试条件不可比。问题四，"团队不会怎么办"——给出三个月的能力建设计划：文档学习、认证培训、社区参与节奏（呼应 8.4），把人力风险转化为可执行计划。这四个问题的答案要在方案成稿时就想清楚，现场组织语言的水平，决定不了评审结果。
POC 环境搭建的最低成本做法
选型 POC 不需要生产级集群，一套最小配置就能回答关键问题：两台中等规格虚拟机做主备、一份脱敏的真实数据、一组压缩后的典型查询。POC 要测的从来不是峰值性能，而是三类适配性：对象兼容通过率（结构加过程全量迁移一遍）、典型查询的计划质量（统计信息收集后看执行计划合理性）、运维工具顺手度（备份、监控、切换各走一遍）。三天就能出结论的 POC，别拖成三周——选型阶段的拖延会被全额计入项目工期。
常见追问的口径库
选型答辩之后，采购与法务环节还有一轮追问，口径提前备好。追问一，"开源软件出了安全事故谁担责"：口径是社区版的责任边界按开源协议约定，企业生产环境建议叠加商业支持合同获取时效承诺，同时说明开源性反而让安全审计可深入源码。追问二，"后续版本的升级服务谁提供"：社区版按社区升级路径自助，商业发行版按服务合同执行，方案里写明选择与预算。追问三，"与信创目录的关系"：按当期目录与行业要求核对，方案中引用目录条目而非泛泛而谈。追问四，"出南墙了能不能换"：迁移退路的成本评估——正因内核源自开放生态，从 openGauss 迁往 PG 系的成本远低于从闭源产品迁出，这条退路本身就是谈判筹码。口径库备齐，选型方案才算真正准备好上会。
对比表之外：三个容易漏算的成本项
对比矩阵之外，总拥有成本里还有三个常被漏算的项。迁移期的双轨成本：新旧两套系统并行运行期间的机器、人力与同步通道投入，常占总成本的两位数百分比。兼容层的长期维护成本：方言适配层用得越深，后续版本升级的核对成本越高，这笔账在技术债台账里要单列。人才市场的供需成本：openGauss 经验工程师的存量虽在快速增长，比 MySQL 人才仍少一个量级，关键岗位的招聘周期要按更长时间预算——或者用内部培养对冲，8.4 的季度节奏就是为此设计。漏算这三项的选型方案，预算执行到中段必然超支；把它们摆上桌面，才是对决策者负责的对比分析。
本节要点回顾
- 先约束后结论：合规、预算、窗口、人力四类约束决定读表方式；
- openGauss 的差异化：发行版内建高可用组件 + Oracle 兼容插件 + 开源可控三条边；
- 不要迷信通用跑分：用自己业务的数据回放做 POC，对象通过率比跑分有说服力；
- 存量决定路径：Oracle 存量走兼容插件路线，MySQL 存量重点评估方言与存储过程改造量；
- 人才是隐性成本：PG 背景团队切换 openGauss 几乎无摩擦，纯 MySQL 团队要预留学习期。
选型落定，合同签了，机器到货了。第 2 章开始，我们进入机器内部：一条 SQL 发进来，openGauss 内部谁接单、谁干活、谁记账。