大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
先说一个我观察到的变化。2026 年上半年，国产数据库的市场开始用脚投票了。前两年，国产替代的订单大多集中在党政。今年不一样，能源、金融、医疗、交通、制造，一个行业接一个行业地铺开。选型会上被问到的问题也跟着变了。以前问"有没有国产可选"，现在问的是"选谁更确定"。这两句话之间，隔着一个分水岭。国产数据库已经过了"能不能用"的阶段，正在进入"好不好用"的阶段。能用只是入场券，好用才是往后几年要一起过日子的东西。
国产数据库怎么选？我的答案很朴素。过了"能用"这一关，还剩四道关：兼容够不够深、迁移敢不敢切、核心扛不扛得住、架构走不走得远。这几年我经手、也旁观过不少选型，下面把四道关逐个拆开讲。
一、兼容：别停在"语法能跑"
选型评标，最常见的一张表，就是兼容度百分比。95%、98%，看着都漂亮。但说实话，这张表很多时候只量了最浅的一层。
兼容不是二元的，它分层。我把它分成四层。语法级，语句能不能解析、跑不跑得起来。基础语义级，结果在逻辑上对不对。末梢语义级，在边界、极端场景下，行为还跟原来一致吗。最后是性能适配，语义对了，跑得够不够快。
| 层级 | 解决什么 | 典型的坑 |
|---|---|---|
| 语法级 | 语句能解析、能执行 | 直接报语法错误，一眼可见 |
| 基础语义级 | 结果逻辑正确 | 函数返回值、运算符优先级 |
| 末梢语义级 | 边界场景下行为一致 | NULL 处理、约束检查时机 |
| 性能级 | 语义对了，还要够快 | 迁移后查询变慢 |
拿末梢语义举个例子。Oracle 里，(1, null) 和 (1, null) 不算违反联合唯一主键，因为它认为 NULL 不等于 NULL。换一个库，这个判断未必一样。只做到语法兼容，迁完之后这条约束就悄悄失效了，数据开始重复录入，等到对账对不上才发现。这类坑，功能测试基本测不出来，得上生产、上高并发才炸。
除了这四个层级，还有个容易被忽略的维度，协议级。有些老应用，代码一行不想动，驱动也不想换，只想把连接地址改一下就接过去。能做到这一步的库，迁移时的摩擦会小很多。
最上面一层是性能级。语法过了，语义也对了，结果迁完查询慢了一截。前面几层做得再好，业务体感照样打折。所以评估报告里那句"性能平替"，我会追问一句：是拿多大的数据量、什么并发压出来的。百分比为什么容易虚高？分母和口径，各家定义不一样。所以我更信一件事：拿自己的业务 SQL 和存储过程，实打实跑一遍。看兼容性，我现在还习惯专门问一句：末梢语义，你们怎么对齐的。这一个问题，往往比十个百分比都管用。
二、迁移：不是"搬得走"，是"敢不敢切"
迁移最贵的从来不是软件，是人。几百个存储过程靠手工改，能改到怀疑人生。但比"搬得动"更要命的一件事，是"敢不敢切"。
割接那天，业务不会停一整天等你导数据。稳妥的做法，是拆成两段。存量用迁移工具先搬过去，增量交给同步工具一直追。搬完还不算完。真正让人睡得着觉的，是有没有退路。
割接之前，还有一步不能省：先评估。对象有多少、哪些能自动转、哪些要人工改，得先有一张清单。没做过评估、直接开导数据的项目，我见一个延期一个。工作量摆在那儿了，排期才敢往下走。迁完之后还有一道关，数据比对。表级、行级、摘要级逐层对一遍，确认逻辑和数据都没走样，才敢进割接。
回到那三件事。评估、迁移、同步，是三件不同的活儿。指望一个工具全包，往往哪件都做不透，得拆开看。金仓那套工具就是照这个分下来的：评估是 KDMS，先把源库扫一遍，对象有多少、哪些能自动转、风险点在哪，列成一张报告；全量数据是 KDTS；增量那头是 KFS，全称金仓异构数据同步软件 Kingbase FlySync。三件事各管一段，哪一段松了，整条链都别想稳。
KFS 有个细节我印象很深。迁移期间最怕的，是存量数据和增量数据对不齐。它的做法，是源端缓存一份静态版本、目标端定格一个快照，两边比对。公开资料里给过一组数：某核心系统从 Oracle 迁到 KES，存量 4T+、日增 50G+，一致性校验从全量六小时以上压到增量十分钟以内，校验时业务机 CPU 负载增加不到 3%。数据库切换带来的停机时间，也从半小时压到了两分钟。配套的还有"双轨并行"。新老两套库同时跑，实时同步。切主之后，老的那套还能当回退用。切换是分钟级，回退是秒级。退路留到这个份上，切的时候心里才有底。
三、核心：扛不扛得住"不能停"的业务
外围系统好换。OA、门户、报表，逻辑简单，几个月就能完事。核心系统完全是另一回事。交易、账务、计费，不能停，也不能错。这条分水岭，看案例最直接。而且有个诀窍：别只看它上没上线，看上线的系统"敢不敢停"。我按行业捋几个公开案例。
制造业。中国一汽的替换，先拿 OA 做试点，跑通了再往生产、车联网、供应链推。前后累计部署2400多套数据库实例，适配上线300多个应用系统，覆盖 20 多类核心业务。
金融。资金交易这块，ComStar 的资金交易管理系统迁到金仓之后，走的是百日稳跑。日终批次耗时省了约两成，部分复杂查询快了接近三倍。另一家头部基金公司的 TA 系统，公开口径是性能提升了 35 倍，把清算的时效红线保住了。
能源和交通。国家电网的智能电网调度系统，覆盖 26 个网省，一跑十几年。轨道交通那边，合肥的互联网票务系统，高峰时每秒几千次扫码，也扛住了。海外也有落地，中国外运的一带一路陆运系统、东盟电力的数字化项目，用的都是国产库。
看案例还有个门道。同一家供应商，外围案例堆得再多，也抵不过一个核心案例。我会挑那种"停一分钟就上新闻"的系统去问。问到了，比翻十页 PPT 都踏实。这些系统有个共同点：不能停。测试环境跑通不算数，生产环境跑得住才算数。它们大多还得过等保、密评这一关，合规不是签个字就完事的。
四、架构：别选一条走到头的路
选数据库，是在选未来五到十年的技术路线。只做集中式的库，眼下够用。但两年后业务量涨上去、数据模型变复杂，可能还得再迁一次。二次迁移的账，往往比第一次还贵。
2026 年能看到一个明显的转向：从"一事一库"走向"一库多模"。以前是关系库存业务、时序库存指标、文档库存日志，中间挂一堆同步和 ETL。现在流行把这几个模型收进一个内核。
金仓走的也是这条路。这个转向我认同，原因很简单：数据模型一多，跨库拼接的活儿就多，也最容易出错。它的做法是把好几类数据收进一个内核，时序数据带专门的压缩和时间分区，空间数据有现成的空间函数，跑在 MongoDB 上的文档应用改个连接就能接过来，向量检索也能跟业务字段一起查。落到我手上，最直接的感受是以前要跨库拼的查询，现在一条 SQL 就能下。它自己把这套叫"五个一体化"，多语法、多模数据、多架构、多场景、开发运维，说穿了，就是别让企业在好几套库之间来回倒腾。举个公开场景：查"过去七天在机场五公里内停留超过三十分钟的车"，时空联合，毫秒级返回。放在两套库的架构里，这就得在应用层拼，开发量大，还容易对不齐。
五、四问决策框架
把上面四道关收一收，我压成四个问题。评审时带着问，不容易跑偏。
| 关卡 | 要问的问题 | 看什么证据 |
|---|---|---|
| 兼容 | 末梢语义对齐了吗 | 兼容性分层报告、边界用例 |
| 迁移 | 切了之后能退回来吗 | 迁移工具链、双轨方案、校验手段 |
| 核心 | 有没有"不能停"的案例 | 同类行业、长周期运行的生产案例 |
| 架构 | 五年后还要再迁一次吗 | 多模能力、集中式到分布式的演进路径 |
第一关和第四关，最容易被跳过。前者因为"百分比好看"，后者因为"眼下够用"。跳过的代价，后面都要还回来。
这四关，金仓是我在不同行业项目里见得比较多的一个。倒不是它名字响，是这几个问题它都能拿东西来对：末梢语义怎么对齐、迁移链怎么拆、有没有能扛"不能停"的核心案例。尤其末梢语义对齐和回退机制，选型会上最容易加分，也最容易被漏问。这四个问题，最好在选型早期就摆上桌。等产品定了、预算批了，再回头补，改起来的成本就高了。
六、避坑清单
第一，别只看兼容百分比。问清楚它说的是语法级还是语义级。末梢语义那一层，最容易藏着反直觉的坑，也最容易被一句"兼容 95%"糊过去。
第二，把回退方案写进割接预案，并且真演练一遍。我见过只签字、不演练的项目。真出事那天，全组手忙脚乱。练过和没练过，完全是两种心态。
第三，别为"追新"而上分布式。我早年吃过一个亏。客户业务量其实没到，硬上分布式，SQL 写法、跨分片事务全要改，测试周期翻了一倍。集中式能扛住的场景，就别急着动架构。
写在最后
国产数据库怎么选，说到底是把"能用"之后的事想清楚。兼容要往深里看，迁移要留退路，核心要有"不能停"的履历，架构要能陪你走五年。过了"能用"这一关，接下来比的是稳不稳、省不省、能不能走得更远。
金仓的底子，在这几条上给得比较足。内核是自己可控的，兼容做到了语义那一层，迁移从评估到同步有一整套工具，核心系统上的案例从电网调度铺到金融交易，架构上又是多模融合的一体化。对正在做选型的人来说，是个值得放进候选、再用真实数据验一验的选项。
你手里的项目，现在卡在哪一关？是兼容评估，还是割接演练？评论区聊聊，咱们互相避坑。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋