年初的选型评审会，我到现在都记得那张会议桌。左边 OceanBase 的资料册摞了一尺高，右边 KingbaseES 的，薄一点。这俩往那一摆，就是国产数据库两条路线的对决，Paxos 分布式对集中式（或共享存储）。会开了三个小时，茶水续了三轮，最后所有人吵的就一件事：同一条 SQL，两条路上各要跑多远。
背景说一句。那阵子单位在赶信创替换的窗口期，Oracle 的 license 账单就摆在台面上，两个候选都给了 PoC 环境，测试时间满打满算三周。会议室里一半人站分布式，说技术新、能扩展；另一半泼冷水，说我们那点数据量根本喂不饱分布式。吵到僵住，老刘把白板一拍：都别吵概念，两类 SQL 各跑一遍，账算出来再说。
这篇就是当时的账本，四个维度：架构效率、复杂 SQL、资源消耗、运维成本。算完的结论先放这——多数政企系统的体量下，KingbaseES 这条路更省，也更快。
一、先算延迟账：一条事务要跑几站路
这是最底层的一笔账，我们当时从 OceanBase 开始扒。
OceanBase 的底座是 Paxos 协议。一条写事务进去，变更要先写日志，日志要同步到多数派副本，多个节点达成一致之后，客户端才能收到确认。明白这层以后，延迟账就清楚了。一笔提交，至少一趟跨节点网络往返，逃不掉。同机房 RTT 零点几到一两毫秒；跨机房就难说了，几毫秒起步，几十毫秒不算罕见。这笔开销，是分布式一致性换容灾能力的底价。优化做得再狠也抹不掉——它就不是代码问题，是物理问题。老刘当时在投影仪上画了条链：客户端、代理、三台副本节点，一圈箭头连下来，会议室里没人再反驳。
读也不全是便宜账。强一致读同样要跟副本交互确认版本，弱一致读虽然快，但业务上"能容忍读到旧数据"的场景并没有想象中多。再加上 OceanBase 的存储引擎走的是 LSM-Tree 路线，数据先在内存的 MemTable 里攒，再层层合并落盘，读一条数据可能要翻好几层结构，读放大是这套架构与生俱来的代价。
金仓这边，是另一本账。提交在单节点内办完：内存改数据，日志落本地盘或共享盘，确认马上回。就这么三步。中间不用等别的节点点头，多数派那些事完全不存在，内存操作本来就是纳秒到微秒级的活。读也一样，块式存储引擎，一次索引定位加一次页读取，数据到手。至于高可用，共享存储形态下交给存储层的冗余和节点切换，执行路径照样单点。当时我数着这三步给评审会讲，讲完对面安静了几秒。
算到这里，桌上有人嘟囔了一句：这不就是用网络往返买一致性，跟用本地提交换低延迟嘛。话糙，理不糙。做在线交易的，每一笔延迟都是成本，两条路的起点差着一截，这是第一笔账。
延迟这玩意，业务侧的体感是最真实的。柜台系统点一下提交，前端有超时预算；支付链路里每一跳都有毫秒级约束；报表跑批要是拖到白天交易时段，两拨用户互相挤。集中式架构下，事务延迟就是本地内存加本地磁盘的叠加，多少预算花在什么上，一目了然。分布式架构的延迟里混着网络抖动、多数派副本的忙闲、跨机房链路的时延，链条一长，最差情况就难预测。做容量规划和压测的人都懂：平均延迟好看没用，P99 才要命。多一跳网络，P99 的尾分布就多一分变数。
共享存储这边我再补两句，免得有人拿"单点"说事。KingbaseES 的共享存储集群，故障切换靠心跳检测加盘阵冗余，备机接管的时间窗口是分钟级甚至更短；最关键的是，切换之后执行路径不变——还是单点执行，还是本地提交。也就是说，高可用的代价被放在了存储层和切换机制上，日常的每一次事务提交，并不为高可用额外付延迟。
二、再算 SQL 账：复杂语句谁的执行路径短
光讲架构是虚的，我们把评审会上吵得最凶的那类 SQL 拿了出来。多表关联、嵌套子查询、窗口函数三样俱全，业务里满地都是：
SELECT dept_name,
emp_name,
ROW_NUMBER() OVER (
PARTITION BY dept_id ORDER BY salary DESC
) AS rank_in_dept
FROM (
SELECT e.emp_id, e.emp_name, e.salary, d.dept_id, d.dept_name
FROM employee e
JOIN dept d ON e.dept_id = d.dept_id
WHERE e.hire_date > '2020-01-01'
AND d.dept_id IN (
SELECT dept_id FROM dept_budget WHERE budget > 1000000
)
) t;
最里层子查询筛部门，中间层两张表关联，最外层窗口函数做部门内排名，一共三层。
这条 SQL 在 OceanBase 上，优化器开工前得先回答"数据在哪"。employee 和 dept 的分片键要是对不上，关联就得把其中一方的数据在节点之间倒腾一遍，中间结果过网线；窗口函数按 dept_id 分区排序，分片键再对不上，还得再攒一轮跨节点聚合。我不是说它跑不动——并行框架、广播表这些家伙什它都备着——而是说这些手段本身也要花钱：广播表多一份存储和维护，并行吃的是机器资源，统计信息的全局收集也比单机复杂，执行计划选错的概率跟着变大。
第二条 SQL 老刘捂了一个礼拜，评审前夜才甩出来，相关子查询套累计窗口：
SELECT o.cust_id,
o.order_date,
o.amount,
SUM(o.amount) OVER (PARTITION BY o.cust_id ORDER BY o.order_date) AS cum_amount,
(SELECT COUNT(*) FROM refund r
WHERE r.cust_id = o.cust_id AND r.order_date <= o.order_date) AS refund_cnt
FROM orders o
WHERE o.cust_id IN (SELECT cust_id FROM vip_customer WHERE level >= 3);
老刘甩完这条，补了句：看懂子查询引了谁，才算看懂这条。我瞅了半天才回过味——refund 那层把外层每一行的 cust_id 和 order_date 都引过去了，照字面意思，每行订单都得去 refund 表里数一遍。老刘管这条叫照妖镜。
集中式数据库的优化器不慌，这玩法它见多了，一次 group by 加一次关联就改写掉，"每行一查"变"两遍扫完"。分布式环境里，同样的改写要牵扯跨节点的数据重分布，优化器敢不敢动手、动了手稳不稳，全看数据分布的脸色。PoC 那两周，这类语句最能看出门道。
KingbaseES 这边没这层烦恼。两张表的关联在本地内存里 hash join 或者索引嵌套循环，子查询交给优化器上拉展开，窗口函数本地排序完事。整条 SQL 从进来到出去，数据没迈出过这台机器。同样的语句，一个是家里跑，一个是跨城搬东西，差距不在技巧，在物理。
还有一个容易被忽略的差别：执行计划的稳定性。集中式数据库的统计信息收集的是自己那一亩三分地，全表扫描一遍就能拿到精确的行数和数据分布，优化器据此选的计划基本靠谱。分布式环境下，数据分布随分片策略、迁移扩容动态变化，统计信息的时效性和全局性都打折扣，同一条 SQL 今天走这个计划、下个月换个计划的事并不少见。对生产系统来说，执行计划飘，比单次跑得慢更折磨人——排障的时候你甚至复现不出来。
这段得补一句公道话，免得有人截图断章取义：分布式架构不是没本事，是它的本事不在这个体量上，第四节细说。
三、再算资源账和运维账
吵完 SQL，评审会进入算钱环节，气氛反而平静了。
先看机器。OceanBase 的多数派要三副本，生产三节点起步，每台 OBServer 的内存占用不算低——LSM-Tree 的 MemTable 和块缓存都要吃内存——数据又实实在在存了三份，存储放大三倍。你要问我值不值，得看业务：几百 GB 到几 TB、几百并发的典型政企负载，这套投入里有不小一块是在给"以后能水平扩"和"跨机房容灾"预付的。将来用不用得上，没人打包票。
KingbaseES 的起步就轻巧：一台主机带一台备机，两份副本，大多数 OLTP 业务的可靠性要求就罩住了。不够再加，共享存储集群把冗余下沉到盘阵，计算节点该怎么省还怎么省。服务器台数、内存条数、机柜电费，同一个业务两张账单，差得肉眼可见。全国产化采购里，这部分差额还要再乘一个系数——信创服务器本来就不便宜。
运维我单独拎出来说，因为信创项目的痛在这。分布式体系的组件面宽：OBServer 之外，管理平台 OCP 要盯，代理层 OBProxy 要管，租户和资源池的概念得先学明白，扩容缩容、副本恢复、流量路由全是新功课。升级更是精细活，滚动升级窗口里要照顾多数派，一步走错就是可用性事件。KingbaseES 这边好办，备份监控调参都是老套路，组里现成的人直接顶上。项目里最贵的成本其实不是机器，是有空的人手——而懂分布式数据库的 DBA，市面上比集中式的难招得多，工资也不是一个数。
备份体系也能算一笔。分布式数据库要保证跨节点的全局一致性备份，通常是分布式快照加增量日志配合，恢复演练的流程复杂，演练一次要动用不少人力。集中式的备份就是全量加归档日志的老配方，恢复演练闭着眼都能做。信创项目普遍有等保要求，备份恢复演练是每年的固定节目，这笔账每年都要付一次。
再说生态适配。信创环境的特点是栈上每一层都是新的，数据库跟国产芯片、国产操作系统、中间件之间的适配认证，直接决定项目能不能落地。金仓在这条路上走的时间长，主流信创 CPU 和操作系统的适配面铺得开，遇到兼容问题能找到的案例和工程师也多。选型的时候，这一项往往比纸面参数更管用。
四、选型的边界，也就是金仓赢在哪
最后这段得把话说圆。OceanBase 不是不能打，它的舞台是真正的超大规模：单库扛不住的数据量、跨机房容灾的硬指标、互联网式弹性伸缩。这些场景里，Paxos 那套架构就是标准答案，我第一个认。
可回头看看信创主战场。政企的 OLTP 加报表混合负载，几个 TB 以内，几百连接，要的就是延迟稳、运维省。这个体量落在集中式的舒适区：架构开销小，复杂 SQL 直接跑，机器和人力都省。
把四个维度的账摆成一张表：
| 维度 | OceanBase（Paxos 分布式） | KingbaseES（集中式/共享存储） |
|---|---|---|
| 写事务提交 | 多数派跨节点确认，必经网络 RTT | 本地内存 + 日志落盘，纳秒到微秒级 |
| 复杂 SQL 执行 | 分片重分布、跨节点聚合、多阶段计划 | 本地 hash join、优化器完整改写、本地排序 |
| 起步资源 | 三节点三副本，LSM-Tree 常驻内存大 | 主机 + 备机两份副本即可 |
| 运维面 | 多组件体系，技能门槛高、人力贵 | 传统集中式经验直接复用 |
| 甜区场景 | 超大规模、跨机房容灾、弹性伸缩 | 政企 OLTP + 报表混合负载 |
所以 OceanBaseVS金仓 的答案，说穿了是谁贴场景。金仓的竞争力在克制。没为了分布式而分布式，省下来的架构开销，都投进了复杂 SQL 的执行效率和更低的总成本。选型会上那三个小时，最后被这张表接住了。
要落地判断也简单，三问自查：一问数据量，单库是否已经超过集中式能吃的范围，几 TB 以内基本不用想分布式的事；二问负载形态，OLTP 为主、报表为辅的混合负载，复杂 SQL 占比越高，集中式的甜区越大；三问团队，组里有没有能养住分布式体系的人，没有的话，运维成本这笔账会逐年放大。三个问题的答案如果都指向集中式，剩下的就是选一款优化器扎实、生态适配到位的国产库——这类选项里，KingbaseES 排在前面，是有原因的。
收尾
散会的时候，我在本子上记了一句：如果业务还没大到需要 Paxos 扛起来，集中式能给的东西——更短的提交路径、更直接的复杂 SQL、更省的机器和人力——KingbaseES 一样不缺。
数据库选型就是算账。账算清楚，选谁自然清楚。
