国产数据库替代的底层逻辑：数据底座为什么必须自主

大家好，我是数据库小学妹 👋 我踩过的坑，你别再踩。

前两周帮朋友公司做数据库选型。他们Oracle授权要续约，费用又涨了一截，老板让看看有没有别的路。会上技术负责人问我："国产数据库替代我们不反对。可我们不是名单上的央企，Oracle用了十来年，真有必要现在换吗？"这话我三年里听了不下几十遍。问的人不是不认国产化，是怕折腾到最后，业务先出了岔子。

先把概念说清楚。数据库是存数据、管数据的底层软件。每一笔支付、每一次挂号、每一笔订单，背后都靠它撑。芯片、操作系统、数据库，被叫作信息时代的三大底座。这篇文章，我把自己的真实感受拆开讲：替代为什么躲不掉，又该怎么理性看待它。先说立场，我平时自己写项目，开源库也没少用。写这篇不是劝谁明天就换。替代是道综合题，想清楚再动，比跟风强。

一、底座攥在别人手里，睡觉都不踏实

先聊最不好笑的那一层：安全。你的存款、社保、电网调度、政务档案，绝大多数存在数据库里。如果这套数据库是海外闭源产品，意味着底层逻辑你完全看不到。看不到，就没法验证两件事：它有没有留后门，它会不会哪天不让你用。

这不是阴谋论。2022年3月，Oracle宣布暂停在俄罗斯的所有业务。不是不卖新产品，是连维护和软件更新一起停。SAP、微软、AWS随后跟上。俄罗斯不少银行、电信、电力系统用的都是Oracle，断供意味着核心系统停摆。这事离我们并不远。断供事件之后，不少企业把"能不能自主"写进了选型表。我服务过的一家国企，评审第一页就是供应链风险排查，数据库排在很靠前的位置。以前大家比性能比功能，现在开场先问一句：出了极端情况，这套库我还用不用得了。

把数据库换成国产的，本质上是把保险柜的钥匙拿回自己手里。这也是为什么替代先从关键行业开始。政务、金融、能源这些领域，数据一泄露就是大事，等不起也赌不起。

二、licence这笔账，越往后越肉疼

第二个理由很俗，是钱。国外商用数据库按CPU、按用户数授权，每年还要交服务费。早年间有报道估算，1997年国内企业买国外数据库服务，一年就要花掉几十亿元。三十多年过去，这笔支出只涨不跌。

看组公开数据。中国信通院统计，2023年中国数据库市场规模约74.1亿美元。IDC数据显示，聚焦到本地部署的关系型数据库市场，海外供应商的收入占比仍有39%。两下一算，一年流向海外厂商的钱，粗估有两百亿元人民币。体感更直接。我见过某国有大行，光Oracle一年的授权加维保，就是几千万元的量级。

企业不是出不起这个钱，是这笔钱花得越来越不值。你年年交着高昂的服务费，换来的却是不受自己控制的底座。说句公道话：省钱不是替换的第一目的。替换本身也花钱，新库要买、应用要适配、团队要培养，前期投入不小。真正的账要拉长了算。一边是年年涨的授权费，一边是一次性的替换成本加可控的服务费。放三五年看，后者未必更贵，还顺带把风险降下来了。现在多数国产库也都有社区版，免费下载学习。学生、小团队想上手，不用一上来就掏钱，门槛低了不少。

三、老架构撑不住新业务，不是库不努力

第三个理由，藏在业务本身。现在主流商用库，大多诞生于上世纪八十年代。那会儿的设计目标，是小型企业、低并发的业务。今天呢？互联网大促、全国政务联动、能源跨区调度，全是海量高并发场景。老架构不是不好，是有物理天花板。再怎么优化，单机集中式的极限就摆在那。

国产数据库这几年的进步，恰恰是被真实场景逼出来的。双11那种极端流量，最早是国产数据库扛下来的。2019年双11，OceanBase把处理峰值做到了每秒6100万次。落到普通企业，体感往往更朴素。去年我帮一家制造业客户换掉核心ERP的数据库。上线前团队最担心性能，结果跑了半年，最慢的那张报表反而比原来快。原因不玄乎：老库受授权限制，很多优化一直不敢动；换库时我们顺手把索引和烂SQL重排了一遍。

说句公道话：国产替代不只是"能用"，在部分场景已经做到"更好用"。不过别急着把"换库"和"上分布式"画等号，这是另一个常见误区。政企大量核心系统要的是稳，不是猛。单库能扛住，集中式照用，没必要为追新而重构。等数据量真到了海量、并发真上了规模，再谈分布式扩展也不迟。先想清楚业务要什么，再谈架构，顺序别搞反。再说一句，现在的业务数据越来越杂，病历是文档，设备带位置，AI辅助诊疗要向量。金仓这类融合型数据库，把文档、时序、空间、向量都收进统一内核，一套库管多种数据，不用堆一堆中间件来回倒。

四、替代不是推倒重来，是分层替换

讲完为什么，很多人会掉进另一个误区：以为国产替代等于明天删光Oracle。真实落地根本不是这样。我见过的靠谱项目，都是分层推进：

这三步各有用意。第一步选外围系统，通常是OA、报表、日志这类挂了不致命的应用，正好让团队练手。第二步挑一个真实业务做试点，比如一张核心大表、一条高频交易链路，跑上几个月，把性能、稳定性、运维手感摸一遍。第三步才轮到规模化，这时候该踩的坑基本踩完了，切换才有底气。割接那晚，预案写了好几页。最要紧的一条：回滚演练必须在切换前真跑一遍，不能只是签个字。真出问题时，练过和没练过，是两种完全不同的心态。

我经手过一个电力行业的替换项目，节奏就是照着这个来的。试点那一步，我们没有急着导数据。先用金仓的KDMS工具把源库扫了一遍，表结构、存储过程、触发器全列出来，自动生成一份兼容性报告。哪些能直接搬、哪些要手工改，标得清清楚楚。兼容性评估报告显示，95%以上的SQL语句和PL/SQL存储过程可以直接执行，不需要修改。2000多个对象，真正需要人工改的不到两成。心里有底了，迁移才敢往下走。后面要做增量同步，用的是金仓异构数据同步软件Kingbase FlySync（简称KFS）。它基于日志解析抓取变更，业务不用停，割接窗口被压得很小。这套流程走下来，客户从部署到割接只用了三天出头。关键不是工具多神，而是每一步都有数。

五、跑了多年信创，我这样看国产库"扛不扛事"

总有人让我推荐国产数据库。我的回答一般是一句：别听广告，看三件事。

第一，它有没有在核心生产系统上连续跑很多年。 测试环境拿奖不算数，生产环境跑得久才算数。国家电网的智能电网调度系统，用的是KingbaseES，据公开资料已经稳定运行了十几年。不止是跑得久，关键时候切换也快。金仓的RAC共享存储集群能做到RPO=0（数据零丢失）、RTO控制在10秒以内，可用性达到99.999%。电力调度这种不能停的系统敢用它，比任何宣传都有说服力。我特意向客户核实过背景，那不是演示环境，是真实的调度生产系统。能在这种系统上待十几年，稳定性是被一天天验证出来的。

第二，它的迁移工具链成不成熟。 迁移最贵的从来不是软件，是人力。几百个存储过程靠手工改，能改到怀疑人生。金仓那套KDMS评估、KDTS迁移、KFS增量同步的组合，我在项目里用过，属于"有人替你想到前面"的类型。评估报告会把对象分成三类：直接兼容、小改可用、需要重构。工作量当场就能估出来，项目排期心里才有底。

第三，厂商服务跟不跟得上。 国产替换最怕一锤子买卖。交付完就找不到人，出了问题只能自己扛。这两年国产厂商都在补服务网络。选型时可以当面问几句：本地有没有支持团队、响应时效怎么算、SLA写不写进合同。答得含糊的，自己多掂量。

把这三条过一遍，心里基本就有数了。顺带提一句，别把各种榜单当圣经。榜单能反映热度，反映不了你那两亿行的表，在它上面到底跑不跑得动。

别把国产化替代，当成"换皮肤"

最后列几条我踩过、也看别人踩过的坑。

第一，别把Oracle的运维经验直接照搬。国产库有自己的脾气，参数、监控、排障思路都得重新学。

第二，迁移前一定先做兼容性评估。跳过评估直接导数据，几百个存储过程会教你做人。返工的成本，比评估高得多。

第三，别被"纯自研"三个字带节奏。自研不自研，要看产品能不能落地，而不是口号响不响。

第四，别指望一步到位。真正跑得稳的项目，都是先试点、再扩大、最后规模化。

关于国产数据库替代，几个高频问题

Q1：中小企业也需要做国产数据库替代吗？

政策不强制的企业，可以先不急着换。但建议早做技术储备。上游央国企一旦要求产业链同步适配，临时抱佛脚会很被动。

Q2：国产数据库能完全替代Oracle吗？

绝大多数通用企业场景可以。前提是提前做兼容性评估、选对技术路线、留足应用适配时间。极少数依赖Oracle特有高级功能的场景，需要做业务重构。

Q3：为什么国产化先从政务、金融开始？

因为这些行业的数据最敏感，也最等不起。它们先跑通，恰恰说明国产库已经具备扛核心系统的能力。

写在最后

刚入行那几年，我也觉得"换库"是件遥远的事。跑了几年信创项目，我的看法变了。替代不是跟风，是把数据底座重新放回自己手里。它不是一锤子买卖，而是一套需要耐心、需要方法的长工程。真正推得动的项目，很少是被口号驱动的，更多是被一张张评估报告和一次次割接演练，推着往前走。

这几年国产库我接触了不少。金仓是我在电力、能源项目里见得比较多的一个。老牌、自研、在调度这类核心系统里能一跑十几年，评估和迁移工具也齐。如果你手里正好有Oracle存量系统要替换，不妨把它放进候选名单，先扫一遍兼容性，用数据说话。说到底，国产数据库替代这事，早晚要面对。早一点想清楚，主动权就多一分在自己手里。

你所在的公司，数据库国产化走到哪一步了？卡在哪一环？评论区聊聊，咱们互相避坑。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见 👋