十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。
干这行十几年，我最怕的不是数据库崩，是有人拿一张 PPT 跟我说"兼容率 95%，放心"。
崩了还能修。数字信错了，工期就回不来了。
所以 电科金仓「Hello，AI 数据库」发布会，很多人盯着 AI 能力看，我盯的是另一件事：金仓在会上把全球化战略正式发布了，愿景写的是"成为世界卓越的数据库产品与服务提供商"。
一家国产数据库说要全球化，这话五年前没人敢写。但话说出来只是第一步，我关心的是更具体的东西——它拿什么让海外客户信，以及这些东西我自己能不能验。
这篇就把金仓 KES 这套东西，按跨境项目的验收逻辑过一遍。哪些是硬能力，哪些是口径，哪些地方还差得远，都说。
01 兼容不是"能跑"，是"改多少"
兼容率是出海选型里被引用最多、被误解最深的一个指标。
先给公开口径：金仓技术博客里给过的数据是，典型迁移场景下 Oracle 对象兼容率 95% 以上，PL/SQL 兼容率超过 90%。
这个数字在国内不算夸张。但我见过太多人把它理解成"我们项目 95% 不用改"，然后翻车。
一个百分比，藏着三个变量。
分母是谁的对象。 是厂商的典型样本，还是你项目里那 3000 张表、800 个存储过程、200 个触发器？你的系统跑了十年，一定有一批"没人敢动"的包，这些往往不在典型样本里。
分子怎么算"兼容"。 能建成功、能编译通过、跑出一样结果、性能可接受——四档标准，对应的兼容率能差二三十个百分点。行业默认的"兼容"多数停在前两档。
那 5% 落在哪。 落在几张报表视图上，两周能改完；落在核心交易链路的存储过程里，是两个月的重写加回归测试。同一个数字，两种命运。
金仓这套的具体做法
兼容这件事，落地时看的不是一句"支持"，是三个层次能不能对上。
第一层是语法层。 KES 在初始化实例时就能选兼容模式，原生兼容 SQL 标准、Oracle、MySQL、SQL Server 和 PG 生态。落到实操层面，就是那些最耗人力的老代码能不能少动：NVL、DECODE、CONNECT BY 层级查询、ROWNUM 分页、序列、同义词，这些 Oracle 项目里遍地都是的写法，在 KES 上多数可以原样跑，不用一行行改。
第二层是 PL/SQL 层。 这一层才是真门槛。存储过程、包、触发器、自定义函数、异常处理块，往往是业务逻辑真正住的地方。PL/SQL 兼容率过 90% 意味着大部分包可以编译通过并正确执行；剩下的那部分，得靠评估工具先扫出来，而不是上线那天撞上去。
第三层是工具链能不能收尾。 兼容率再高，没有配套工具也落不了地。金仓这套是 DTS 做评估和对象转换、DMS 做结构比对，KFS 做全量搬迁加增量追平（基于 logical decoding 的实时同步），走的是"评估 → 改造 → 全量迁 → 增量追平 → 灰度切流"的标准路径。
这条路径在国内项目上跑了很多遍，出海本质上是换个环境再跑一遍。对跨境项目来说，"流程被验证过"比"功能被宣传过"值钱得多。
怎么验
我从来不看对方的报告，只做三件事：
用自己的 SQL 跑。 从生产库的慢查询日志、审计日志、应用埋点里抓全量 SQL，按调用频次和业务重要度排序，前 200 条逐条验证——不是看能不能执行，是对比执行结果和执行计划。
把存量对象分四级。 直通、微调、重写、不支持。要向老板汇报的不是"兼容率 95%"，而是"需要重写的对象 37 个，其中 9 个在核心链路，预计人月 4.5"。
专门验语义。 语法兼容和语义兼容是两件事，这一步最容易被跳过，也最容易在割接当晚出事。
| 现象 | 为什么会不一致 | 怎么提前发现 |
|---|---|---|
| 空串和 NULL 混用 | Oracle 里 '' 就是 NULL，多数库不是 | 扫一遍 = ''、IS NULL 的写法 |
| 隐式类型转换 | 字符串和数字比较时的转换规则不同 | 用边界数据跑，不用正常数据跑 |
| 排序和大小写 | 排序规则不同，ORDER BY、DISTINCT、GROUP BY 结果都会变 | 用多语言样本数据测 |
| 日期函数边界 | 月末、闰年、时区切换返回值的差异 | 造 2 月 29 日、12 月 31 日 23:59:59 的数据 |
| 数字精度 | NUMBER 到 NUMERIC 的精度与舍入规则 | 用金额字段对账，一分钱都不能差 |
顺便提一个和出海关系很直接的能力：64 位事务号。Oracle 的经典坑之一就是事务号耗尽，老系统跑得越久越要担心。KES 用 64 位事务号，这个隐患在架构层面就消掉了。跨境客户的系统往往比国内更老，"不折腾"本身就是卖点。
踩坑提醒：兼容性评估报告一定要写清"测试集来源"和"兼容判定标准"。这两项没有，报告就是广告。
小结：兼容率不是结论，是起点。金仓在 Oracle/MySQL 兼容这条线上的深度是国产里靠前的，但真正有用的还是那句话——用你自己的数据算出来的数，才算数。
02 供应链可信：金仓的牌面在这张桌子上最硬
这一条国内技术人最容易低估，海外客户最先问。
跨境项目里，技术评审之前通常还有一道前置关卡，叫供应商准入。它会问：内核代码是谁写的？用了哪些开源组件、什么许可证？构建能不能追溯？出了 Log4j 那种事，你多久能给补丁和影响面清单？
这不是刁难。全球对软件供应链安全的监管都在收紧，2026 年 3 月国内也施行了《国务院关于产业链供应链安全的规定》。这类要求从"加分项"变成了"材料清单"。
在这张桌子上，金仓的底子是相对硬的：
- 内核 100% 自主研发，核心代码自主可控。 这点在准入问卷里是可以直接落笔的答案，不是"基于某开源分支二次开发"那种需要解释的表述。
- KingbaseES V9 通过中国软件评测中心的软件供应链安全能力三级认证，厂商说法是国内数据库厂商里首个拿到该等级的。
- 数据主权相关能力是成套的：透明加密、细粒度权限控制、全链路审计。这些在国内算加分项，在海外是入场条件。
我得说句冷静的话，否则这篇就成了通稿。
第一，认证解决的是"你有没有体系"，不解决"你的体系符不符合他们的法律"。 国内机构发的证书，在海外招标里通常只能作为参考材料，客户还会要自己的问卷、自己的渗透测试报告、自己的数据出境评估。指望一张证书通关，不现实。
第二，供应链信任攒不快。 它靠一次次交付、一次次漏洞响应记录堆出来。这也是我判断国产数据库出海最慢的一环——比技术慢，比价格慢，比生态还慢。
第三，能拿出来比说得好听重要。 我评估供应商会直接要四样东西：SBOM 清单（含许可证）、构建可追溯说明、高危漏洞响应时限（写进合同的那种）、数据主权技术材料。这四样拿不出来，性能测试做得再漂亮，也走不到技术评审。
金仓在这块的优势是"材料能成体系地交出来"，而不是"某一条特别突出"。跨境项目里，前者才管用——客户是按清单打勾的，缺一项就打不下去。
踩坑提醒：数据主权要求在不同市场差别极大。同一个加密方案，在 A 地区是合规刚需，在 B 地区可能因为密钥管理位置不合规被否。别拿一个市场的方案套所有市场。
小结：供应链是材料题。金仓这块的牌面在国产厂商里属于拿得出手的一档，但真正的考场是海外客户那份问卷，不是发布会的 PPT。
03 多模与库内 AI：一条 SQL 就能验真假
"多模"这个词现在热到有点贬值，几乎每家都说自己支持关系、文档、时序、向量、图。
我判断的标准只有一个：一条 SQL 里能不能同时做完两种模型的查询，并且是一个执行计划。
在库里做，还是在外头拼，是两回事。
-- 关系过滤 + 向量相似度，一次查询完成
SELECT p.product_name,
p.price,
1 - (p.embedding <=> :query_vec) AS similarity
FROM products p
WHERE p.category = 'electronics'
AND p.price BETWEEN 1000 AND 5000
ORDER BY similarity DESC
LIMIT 10;
验证动作很简单：让对方当场执行，然后看执行计划。
- 一个计划，过滤和向量排序在内核里一起完成——真融合
- 计划里出现外部函数调用，或者要分两次查询在应用层合并——外挂，只是包装得整齐
金仓的多模是内核级的：关系、时序、文档、图、K-V 收在同一个内核里。今年 6 月香港科技园那场公开沙龙上，现场演示过一条 SQL 同时操作关系数据、向量数据、JSON 半结构化数据和图数据。
从工程角度看，这个方向是对的。四套库意味着四个连接池、四份备份策略、四套权限模型，外加一条永远对不齐的同步链路。系统越老、越杂，这笔账越贵——而出海客户面对的恰恰都是"老、杂"的系统。
AI 这块，金仓走的是"数据不出库"
发布会上讲的三个能力都在库内：库内语义构建、库内计算推理、库内原生安全管控。核心一句话叫"数据不出库，AI 也能用"。
这条路线在出海语境下比在国内更值钱。你把向量库挂在外面，数据就已经出过一次边界了——GDPR 这类要求下，这不是技术选型问题，是合规问题。
公开的实测口径是：1 亿条 768 维向量、98% 召回率条件下，峰值内存开销比业界方案降低 95.4%，查询延迟降低 80%。
这组数字如果成立，意义不在省钱，在能不能落地——从"要堆 TB 级内存"变成"常规服务器能跑"。跨境客户的机房条件往往比国内紧，这个差别就是"能上"和"上不了"。
但我看这类数字，一定先问四个条件：向量维度、数据集大小、召回率怎么定义、单机还是分布式。四个条件不写清楚，数字不能横向比较。行业里常见的失误是拿百万级的验证结果，去做十亿级的容量规划。
至于向量检索本身，还有一条经验：性能曲线不是线性的。数据量翻十倍，HNSW 这类索引的内存和构建时间涨得比想象中快。选型按三年后的数据量算，别按今天的算。
踩坑提醒：库内 AI 的价值是"少一套系统"，不是"多一个功能"。如果你的场景只需要一次性的离线向量化，外挂方案也能跑；但只要涉及在线更新、事务一致性、权限继承，融合架构的优势就出来了。
小结：多模别听描述，看执行计划。一条 SQL、一个计划、一次结果一致，就是融合；否则就是拼装。金仓在这条线上是真融合，这是它出海最值钱的一张牌。
04 本地化适配：交付前一公里
产品卖出去是开始，能不能在对方环境里稳定跑，是另一件事。
跨境部署踩的坑，八成不是数据库本身的 bug，是环境差异：
| 差异维度 | 具体表现 | 影响 |
|---|---|---|
| 字符集与排序规则 | 多语言数据、大小写敏感、重音处理 | 查询结果不一致、索引失效 |
| 时区与夏令时 | 跨时区写入、DST 切换当天的重复或丢失 | 时间戳错乱、对账失败 |
| 日期与货币格式 | 本地化格式解析 | 应用层报错 |
| 网络时延 | 跨地域两地三中心 | RPO/RTO 要重算，同步复制可能拖垮主库 |
| 合规与许可 | 数据出境、加密要求、许可证条款 | 架构要改，调参解决不了 |
| 运维时区 | 跨时区 7×24 响应 | 故障响应时长按合同算 |
这些项靠"上线后再说"是过不去的。我的做法是做成一张测试矩阵：每个维度列出测试用例、预期结果、验证方式，交付前逐项打勾。
金仓在这块的积累是有实体的。今年 6 月香港那场沙龙上，LSCM 的分享主题就是《数据库在本地化适配测试实践》，把"产品在内地跑得好、到香港就水土不服"这件事拆成了一套可复用的测试方法；香港本地交付伙伴复盘的项目覆盖金融、政企、商贸行业。这些是港澳市场，不是全球市场，但至少说明这套方法是真跑过项目的。
运维侧同理。跨时区、跨地域的 7×24 响应，靠的是集中化监控——金仓这套是 KEMCC 统一运维平台，把多套实例的监控、告警、巡检、备份收敛到一个界面。听着不性感，但客户半夜出事的时候，只认这个。
高可用这块也得对上账。跨境项目的两地三中心不是换个参数的事：RPO=0 意味着同步复制，跨地域的网络时延会直接拖慢主库事务提交。金仓在这块给的是 RAC 集群 + 流复制的组合，公开口径是 RPO=0、RTO 30 秒以内。到了跨境场景，这个 30 秒要按实际链路时延重新测，不能照抄。
踩坑提醒：灰度切流阶段最容易出问题的是长事务和批量作业。白天切了读流量一切正常，凌晨跑批直接把延迟顶上去。切流前一定要把批处理窗口单独压一遍。
小结：本地化适配不是"翻译界面"，是把环境差异一项项测出来。交付前测一公里，胜过上线后救一个月。
三种验证深度，你该走到哪一步
| 深度 | 做法 | 能验证什么 | 验证不了什么 | 成本 |
|---|---|---|---|---|
| PPT 验证 | 听介绍、看演示、读白皮书 | 产品和方向 | 你的系统能不能跑 | 最低，风险最高 |
| 沙箱复现 | 搭环境、导数据、跑自己的 SQL | 兼容性、语义差异、性能基线 | 生产负载的真实形态 | 中，多数项目的最低要求 |
| 生产灰度 | 真实流量按比例切、双跑对账 | 长稳能力、极端场景、运维配合 | 大规模并发下的天花板 | 高，核心系统的必经之路 |
我的建议很直白：核心系统不走完第三档，不上线。 非核心系统至少走完第二档。只做第一档就拍板的项目，我见过，结局通常不太好。
顺便说，金仓在这三档上是愿意配合的——沙箱环境、迁移评估、灰度方案都能落地成具体交付物。RPO=0 给的是承诺，敢不敢让你在生产上验，才是诚意。
深度分析：出海真正的门槛是"可验证性"
把上面四条串起来看，会发现一个共同的底层逻辑。
海外客户不缺数据库。Oracle、MySQL、PostgreSQL、云厂商托管服务，选项多得很。他们缺的是能降低自己决策风险的东西。而降低风险的方式只有一个：让结论可以被独立复现。
这解释了几件看起来反常的事：
- 为什么供应链材料比跑分重要？因为材料可审计，跑分不可复现。
- 为什么本地案例比总部案例重要？因为本地案例能被同行验证。
- 为什么"兼容率"要拆成对象清单？因为清单能被逐条核对。
沿着这个逻辑看金仓的全球化，就比较容易判断它处在什么位置。
它选的是"能力竞争"这条路，不是"价格竞争"。 兼容 Oracle 加便宜，在海外没有机会——那边一抓一大把的 PG 发行版比你更有本地根基。所以它把牌押在 AI 原生加多模融合上：这条线全球范围内都还没有既定的标准答案，谁先做实，谁就有机会参与定义。
它的路径是渐进的。 AI 能力分三层落地：高可用从"故障后切换"往"故障前预警"走，比如 MAA 结合内核级分析做多指标综合判断，而不是只看心跳超时；运维从"阈值告警"往"诊断建议"走，KEMCC 给出根因和处理建议，最终执行权还在 DBA；向量计算直接做进内核，用 SQL 就能调。没有一步到位搞全自动——这个选择不惊艳，但对企业靠谱。
它也有明显的短板，得说清楚。 生态是硬伤：驱动、社区、云市场上架、ISV 适配、大学课程，国外厂商攒了二三十年。金仓自己的技术博客给过判断，未来一到三年，出海要从"可用"验证期进入"好用"和"可信"的深水区，这话我认同。
竞争对手也不是原地不动。 截至公开信息，OceanBase 2025 年 10 月宣布全面提速全球化，除了港澳、东南亚还进了日本市场，当时披露的数字是深度接洽 70 多家海外客户、40 家签约付费。国产数据库出海不是一家的事，是一场集体补课，而且已经有人跑在前面。
所以我的判断是：技术能力决定你能不能进场，可验证性决定你能走多远。 金仓在前者上已经拿了入场券——兼容深度、供应链材料、多模内核,这三样是真的;后者要靠时间和一次次交付攒。
检查清单：跨境项目数据库验收
技术负责人可以直接拿去用。
兼容性
- 用生产 SQL 全量抓取，不用厂商样本
- 兼容性判定标准写进验收条款（四档定义）
- 核心链路对象单独列清单，逐个签字
- 语义差异专项测试（NULL、类型转换、排序规则、精度、日期边界）
- 确认事务号位宽、序列上限这类长期隐患
供应链与合规
- SBOM 清单，含许可证
- 构建可追溯说明
- 漏洞响应 SLA 写进合同
- 数据出境、加密、审计能力逐项材料化
- 第三方认证作为参考材料，不作为通关凭证
能力验证
- 多模能力看执行计划，不看演示视频
- 库内 AI 做一次"数据不出库"的完整验证：写入、更新、检索、权限
- 性能数字带完整测试条件（维度、数据量、召回率、部署形态）
- 按三年后数据量做容量规划
交付
- 本地化适配测试矩阵，逐项打勾
- 每个迁移阶段有可交付物
- RPO/RTO 在真实网络链路时延下重测
- 批处理窗口单独压测
- 回滚方案经过演练，不是写在文档里
最后
这十几年我最大的转变，是从"信数字"变成"信自己能复现的数字"。
金仓这次的全球化战略，我给的评价是：方向对，底子够，路径稳，但离"世界卓越"还有很长的路。兼容率 95%、供应链三级认证、多模内核、库内 AI 这些，都是实打实的东西，不是包装出来的概念——这也是我愿意花一整篇去拆它的原因。
但这些都不是给你的结论，是给你核对的起点。跨境项目上没人会替你承担信错数字的代价。
所以看一家数据库厂商能不能出海，我不看发布会说了什么，看三件事：敢不敢把测试集交给你、敢不敢把材料清单摊开、敢不敢让你按自己的节奏灰度。
金仓这三条我目前看是敢的。剩下的，交给明年的签约数和本地团队数去回答。
下一篇回到老本行，聊主备切换和故障转移里的那些坑。跟着一篇篇看，数据库这块的事就不容易出岔子。
有问题评论区见。
十五年数据库领域老炮。关注我，一起把数据库这件事搞明白。
