1.3 选型对比：Oracle 与 PG、MySQL 及国产库
1.3 选型对比：Oracle 与 PG、MySQL 及国产库
本节摘要：选型评审会上最没用的句话是"X 也很成熟"。本节把 Oracle、PostgreSQL、MySQL、达梦、openGauss、OceanBase 放到成本、高可用、兼容、生态、能力边界五个同维度上对质，给出"什么场景选谁"的决策边界，而不是排名。
一张被逼出来的对比表
某制造企业的数据库选型会上，CTO 把四家厂商的 PPT 摊在桌上后发现一个规律：每家都"性能领先、生态成熟、案例丰富"。他最后只问了三个问题，三家哑了两个——停机十分钟赔多少钱？现有 Oracle PL/SQL 存储过程有多少万行？运维团队会什么？选型不是比参数，是比"你的业务输不起什么"。这三个问题，恰好对应本节对比的前三个维度。
图 1-2：六款数据库选型决策矩阵
二、五个维度的正面对质
许可与总成本。 Oracle 按处理器核数或用户数计许可费，大型机场景年支出常以百万人民币计，另有年度支持费（约许可价的 22%）。PostgreSQL 与 MySQL 社区版零许可费，成本转移到人力与硬件。但要算总账：开源省下的许可费，一部分会以 DBA 团队扩编、高可用自建、迁移开发的形式回来。规模小、团队强的互联网业务，开源总成本占优；核心交易系统对兜底支持有合同级要求的，Oracle 的账有时反而算得平。
高可用兜底。 Oracle 给的是"合同写明的"组合：RAC 多实例双活、Data Guard 秒级切换、跨站点容灾、原厂 24 小时服务。PG 有流复制与 Patroni 等方案，可用性上限不低，但整套体系靠你自己搭、自己演练、自己背锅。MySQL 主从复制生态成熟，但历史遗留的复制语义弱点（异步复制的丢数据窗口）需要半同步或组复制补足。这里的关键差异是责任归属，不是技术上限。
Oracle 兼容度。 存量系统迁移时这个维度一票定生死。PG 的语法接近但 PL/SQL、包、物化视图细节差异不小；MySQL 差异更大。国产库里达梦以 Oracle 兼容为主打，存储过程迁移成本最低；openGauss 走 PG 内核加企业加固；OceanBase 主打分布式。迁移评估的正确姿势是拿 dba_source 统计代码行数、按对象类型分类打分——本节末尾的案例就是这么做的。
生态与人才。 PG 是过去十年全球增速最快的数据库，新项目选它的机会成本最低；MySQL 在互联网场景人才池最深；Oracle DBA 平均薪资最高但存量岗位在收缩。国产库享受政策红利，区域人才密度不均，二三线城市的招聘难度需要提前评估。
内核能力上限。 分区、并行执行、优化器成熟度、内存列存、多模能力——Oracle 的上限仍是行业标杆；PG 靠扩展生态补（Citus、TimescaleDB、向量插件）；MySQL 在复杂分析与大表管理上短板明显；OceanBase 的分布式水平扩展是 Oracle 单机架构之外的另一条路。上限只在业务触到天花板时才有意义——先确认你会触到。
三、案例：一次真实的去 O 评估
背景。 某支付公司要求核心账务库三年内去 Oracle。第一轮评估直接选了 MySQL，试点两周即搁浅——账务系统 46 万行 PL/SQL，改造预算超千万。
操作。 第二轮评估改了方法：先用数据字典给存量资产分级。
-- 盘点 PL/SQL 资产量：迁移成本的第一输入 SELECT owner, type, COUNT(*) AS cnt, SUM(LENGTH(source))/1000 AS kb_of_code FROM dba_source WHERE owner IN ('LEDGER','SETTLE') GROUP BY owner, type ORDER BY kb_of_code DESC; -- 找出用到的 Oracle 专有特性（示例：分层查询与分析函数） SELECT name, line, text FROM dba_source WHERE owner='LEDGER' AND (LOWER(text) LIKE '%connect by%' OR LOWER(text) LIKE '%model%' OR LOWER(text) LIKE '%bulk collect%') AND type='PACKAGE BODY';
结果。 统计显示 46 万行里 31 万行是简单增删改查与日志逻辑，可自动改写；真正卡脖子的是 9 万行重计算逻辑，大量使用分析函数与批量绑定。最终方案：简单部分迁 PG，重计算部分先用达梦承接（兼容度最高），三年后再按微服务拆解消解存量。解读。 同一个目标，第一轮拍脑袋失败，第二轮靠资产盘点拿到可谈判的方案——选型对比表的价值不在告诉你选谁，在把争论从"信仰"拉回"成本"。变式。 若这是全新项目、零存量，结论完全不同：直接 PG 或 MySQL，兼容度维度整栏作废。存量规模决定维度权重，这就是"对比表没有标准答案"的含义。
💡 关键直觉：选型矩阵的每一格都可以造假，唯独"你现有团队会什么"造不了假。大量失败的去 O 项目不是技术不行，是按"理想团队"配的方案，而实际团队只会 Oracle。
四、把对比表用起来：三种典型场景的结论示范
对比表的价值要看它能不能产出结论，三个最常见的场景各给一个示范判断。
场景一：核心交易库续约或新建。 权重排序通常是兜底、兼容、成本。若业务单笔事故赔付高、团队是 Oracle 老班底，结论多半是"留"，把省下的迁移预算投给高可用演练；若是新建系统且没有历史包袱，PG 加自建高可用的总成本优势明显，代价是团队要真会——不会的"省"是假省。
场景二：政策驱动的国产化替代。 权重里兼容度一票突出。评估动作是先跑 7.1 式的资产盘点，用 PL/SQL 行数与专有特性命中数给候选库打分：兼容路线（达梦类）迁移快但长期绑定深，重构路线（PG 系）成本高但生态独立。两条路线的混合方案——先兼容后重构的十年规划——正在成为大型机构的主流答案。
问题一：对比数据从哪里取才可信？ 三条渠道的优先级：自己环境的 PoC 实测（唯一作数）、第三方公开测试报告（看方法论再看结论）、厂商白皮书（只当功能清单用）。尤其警惕"吞吐提升百分之几百"类表述——基线是什么负载、什么硬件、什么版本，缺一样都无法比较。
问题二：选型要不要考虑团队的成长路径？ 要，而且权重在上升。一个只会 Oracle 的团队五年后价值在哪，和一套 Oracle 系统五年后的成本在哪，是同一个问题的两面。给团队留一条向开源或多模演进的学习曲线，本身就是选型的一部分——这也是为什么很多机构的折中方案是"新系统用 PG 练兵、老系统继续运维"：让演进发生在增量里，而不是把存量推倒重来。
本节要点回顾
- 五维框架：总成本、高可用兜底、兼容度、生态人才、内核上限——先排你的权重，再看别人的分数。
- 成本算法：开源省许可费，但高可用自建与人力成本会回来；Oracle 贵在合同化兜底。
- 兼容度是存量系统的第一权重：用 dba_source 给 PL/SQL 资产分级打分，让迁移成本可计算。
- 国产库三条路：达梦走兼容过渡、openGauss 走 PG 加固、OceanBase 走分布式多活。
- 没有排名只有边界：新项目、存量替换、政策合规三类场景，答案各不相同。
第 1 章到此合上评估单。下一章进入机器内部：先从那块所有会话共享、也最容易出事的内存看起。