OceanBase VS 金仓：别只比QPS，先搞清楚你在为什么场景买单

上周有个老同事问我，核心账务库升级到底该看 OceanBase 还是金仓。他原话挺有意思：“网上截图一个比一个猛，左边说分布式水平扩展无敌，右边说老牌企业库稳得像承重墙。我要的是能过评审的方案，不是海报。”我听完挺有感触。OceanBaseVS金仓这个话题，最容易被讲成信仰之争，真到项目里，反而没人愿意把话说细：你的延迟到底发生在计算、日志、网络，还是执行计划？你的复杂 SQL 是老板报表、实时风控，还是账期批扣？选型不是选冠军，是选“代价放在哪儿”。

我这篇文章不打算端水，也不打算拍性能数字——脱离机型、租户模式、参数、数据倾斜和压测模型谈倍数，基本属于玄学。我想做三件更实用的事：第一，把 OceanBase 基于 Paxos 的分布式架构，和金仓更常见的集中式/共享存储落地形态，在延迟来源上拆开；第二，用一组贴近账务场景的建表、增删改查和复杂 SQL，说明两类系统“擅长什么、别扭什么”；第三，给一套可复用的测试口径，免得评审会又变成截图大战。代码我尽量写成骨架，生产别直接搬，但思路可以直接拿去用。

一、先把话说窄：分布式不是免死金牌，集中式也不是老古董

很多人一谈 OceanBase，脑子里自动弹出四个字：水平扩展。这个印象没错，但不完整。OceanBase 的核心吸引力在于把数据分片、副本一致性、故障切换和高可用打包进一套体系里，底层一致性靠 Paxos 这类多数派协议撑住。好处很明显：节点可以扩，副本可以跨机房放，单点故障不那么吓人。代价也同样清楚：一条写路径不再只是“本机落盘”，而是至少要在多数副本之间达成一致；跨机房部署时，网络 RTT 会直接站到事务延迟的舞台上，还是C位。

金仓这边，企业生产里更常见的形态还是集中式主备，或者再往上走共享存储、集群化的路数。它的强项不在“把一个集群拆成很多片继续加机器”，而在成熟的事务语义、优化器、过程化能力、运维体系和周边工具链。写一笔账，路径短，尾巴少，延迟更好压；问题在于，当单写入口或单实例天花板真的顶到业务增长曲线时，你要更早做拆分、读写分离、归档、分库分表，或者引入同步链路去卸压力。换句话说，OceanBase 把很多分布式难题产品化；金仓则把单机/主备形态打磨得更听话，但扩展的功课常常要提前做到应用层。

我一般会先问客户三个问题：数据量级是不是已经顶到单机写入口？RPO/RTO 到底要多久，能不能接受跨机房强一致带来的延迟税？复杂 SQL 是偶尔跑一次的管理层报表，还是每笔交易都绕不开的链路？这三个答案，比十张宣传页有用。

二、建表别炫技：字段类型和约束，后面都会变成延迟和纠纷

不管选哪边，建表阶段都别浪。迁移评估里最容易被低估的不是大对象，而是默认值、约束、索引和分区键。尤其账务、订单这类系统，今天图省事留一个含糊字段，明天对账、冲正、幂等、稽核全会找上门。

我用一个简化账务场景。OceanBase 侧我按 MySQL 兼容租户来写，贴近很多互联网团队手感；金仓侧用企业库常见写法。别纠结某个关键字在不同版本里的细小区别，重点是结构口径：金额定点，状态收窄，请求号唯一，业务时间和审计时间分开，分区键别和主键抢戏。

OceanBase MySQL 租户示意：

CREATE TABLE acct_balance (
acct_id BIGINT NOT NULL,
balance_date DATE NOT NULL,
currency_code CHAR(3) NOT NULL DEFAULT 'CNY',
balance DECIMAL(18,2) NOT NULL DEFAULT 0,
frozen_amt DECIMAL(18,2) NOT NULL DEFAULT 0,
version_no BIGINT NOT NULL DEFAULT 0,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (acct_id, balance_date)
) PARTITION BY RANGE COLUMNS(balance_date) (
PARTITION p202609 VALUES LESS THAN ('2026-10-01'),
PARTITION pmax VALUES LESS THAN MAXVALUE
);

CREATE TABLE acct_flow (
flow_id BIGINT NOT NULL,
acct_id BIGINT NOT NULL,
flow_type VARCHAR(16) NOT NULL,
amount DECIMAL(18,2) NOT NULL,
flow_status CHAR(1) NOT NULL DEFAULT 'N',
request_no VARCHAR(64) NOT NULL,
biz_time TIMESTAMP NOT NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (flow_id),
UNIQUE KEY uk_acct_flow_req (request_no),
KEY idx_acct_flow_acct_time (acct_id, biz_time),
KEY idx_acct_flow_status_time (flow_status, biz_time)
);

金仓侧示意：

CREATE TABLE acct_balance (
acct_id BIGINT NOT NULL,
balance_date DATE NOT NULL,
currency_code CHAR(3) NOT NULL DEFAULT 'CNY',
balance NUMERIC(18,2) NOT NULL DEFAULT 0 CHECK (balance >= 0),
frozen_amt NUMERIC(18,2) NOT NULL DEFAULT 0 CHECK (frozen_amt >= 0),
version_no BIGINT NOT NULL DEFAULT 0,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT pk_acct_balance PRIMARY KEY (acct_id, balance_date)
)
PARTITION BY RANGE (balance_date);

CREATE TABLE acct_balance_202609 PARTITION OF acct_balance
FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');

CREATE TABLE acct_flow (
flow_id BIGINT NOT NULL,
acct_id BIGINT NOT NULL,
flow_type VARCHAR(16) NOT NULL CHECK (flow_type IN ('RECHARGE','DEDUCT','FREEZE','UNFREEZE','ADJUST')),
amount NUMERIC(18,2) NOT NULL CHECK (amount <> 0),
flow_status CHAR(1) NOT NULL DEFAULT 'N' CHECK (flow_status IN ('N','P','F','C')),
request_no VARCHAR(64) NOT NULL,
biz_time TIMESTAMP NOT NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT pk_acct_flow PRIMARY KEY (flow_id),
CONSTRAINT uk_acct_flow_req UNIQUE (request_no)
);

CREATE INDEX idx_acct_flow_acct_time ON acct_flow(acct_id, biz_time);
CREATE INDEX idx_acct_flow_status_time ON acct_flow(flow_status, biz_time);

这里有一个我自己很固执的点：能写 CHECK 的地方别全靠应用层自觉。不是说应用不该校验，而是数据库这层兜底，能在迁移和联调时帮你抓住“脏流量”。代价当然有一点，写入多几道判断，极端高并发下要测。但账务系统里，错一笔比慢一毫秒更难看。

再补一张汇总表，后面窗口函数和嵌套子查询都要吃它。

CREATE TABLE acct_daily_sum (
sum_date DATE NOT NULL,
acct_id BIGINT NOT NULL,
recharge_amt NUMERIC(18,2) NOT NULL DEFAULT 0,
deduct_amt NUMERIC(18,2) NOT NULL DEFAULT 0,
adjust_amt NUMERIC(18,2) NOT NULL DEFAULT 0,
flow_cnt BIGINT NOT NULL DEFAULT 0,
CONSTRAINT pk_acct_daily_sum PRIMARY KEY (sum_date, acct_id)
);

三、增删改查：真正拉开差距的，常常是事务尾巴和热点行

先把丑话说前面：简单点查、按主键更新，OceanBase 和金仓都能跑得很好看。评审里拿这种 SQL 证明谁更强，意义不大。真正见性格的是三类场景：热点账户、跨分区事务、批量作业。尤其账务系统，大家嘴上谈架构，身体都很诚实地盯着那几个大账户：平台账户、结算账户、渠道过渡户。它们一热，什么设计理念都要接受现实检验。

OceanBase MySQL 租户增删改查示意：

— 幂等入账：重复请求号不重复记账
INSERT INTO acct_flow(flow_id, acct_id, flow_type, amount, flow_status, request_no, biz_time)
VALUES (900001, 10086, 'RECHARGE', 100.00, 'N', 'REQ-OB-0001', '2026-09-13 20:30:00')
ON DUPLICATE KEY UPDATE flow_id = flow_id;

UPDATE acct_balance
SET balance = balance + 100.00,
version_no = version_no + 1,
updated_at = NOW()
WHERE acct_id = 10086
AND balance_date = '2026-09-13'
AND version_no = 7
AND balance + 100.00 >= 0;

— 状态流转 + 流水登记，必须同一个事务
START TRANSACTION;
UPDATE acct_balance
SET balance = balance – 30.00,
frozen_amt = frozen_amt + 30.00,
version_no = version_no + 1,
updated_at = NOW()
WHERE acct_id = 10086
AND balance_date = '2026-09-13'
AND version_no = 8
AND balance >= 30.00;

INSERT INTO acct_flow(flow_id, acct_id, flow_type, amount, flow_status, request_no, biz_time)
VALUES (900002, 10086, 'FREEZE', -30.00, 'N', 'REQ-OB-0002', NOW());
COMMIT;

金仓侧，同样的业务意图，写法不神秘，重点在把边界收紧：

— 请求号唯一冲突就交给约束，别靠“先查再插”装幂等
INSERT INTO acct_flow(flow_id, acct_id, flow_type, amount, flow_status, request_no, biz_time)
VALUES (900001, 10086, 'RECHARGE', 100.00, 'N', 'REQ-KES-0001', TIMESTAMP '2026-09-13 20:30:00');

UPDATE acct_balance
SET balance = balance + 100.00,
version_no = version_no + 1,
updated_at = CURRENT_TIMESTAMP
WHERE acct_id = 10086
AND balance_date = DATE '2026-09-13'
AND version_no = 7
AND balance + 100.00 >= 0;

BEGIN;
UPDATE acct_balance
SET balance = balance – 30.00,
frozen_amt = frozen_amt + 30.00,
version_no = version_no + 1,
updated_at = CURRENT_TIMESTAMP
WHERE acct_id = 10086
AND balance_date = DATE '2026-09-13'
AND version_no = 8
AND balance >= 30.00;

INSERT INTO acct_flow(flow_id, acct_id, flow_type, amount, flow_status, request_no, biz_time)
VALUES (900002, 10086, 'FREEZE', -30.00, 'N', 'REQ-KES-0002', CURRENT_TIMESTAMP);
COMMIT;

这里差别开始显形。OceanBase 如果把热点账户恰好路由到同一台 observer，强一致写路径仍要过 Paxos 多数派；如果热点还被分区策略打散，表面上“分担了”，账务上却可能把单行余额更新变成更难受的跨分区事务。金仓集中式主备在这类单行热点上常常更直白：本地提交快，尾巴短，但要接受主写入口和后续拆分规划。我的判断标准很土：跑批前看 P99，不要只看平均；热点账户单独做一组；同步链路延迟也纳入事务完成时间，不要假装它不存在。

查询也一样。按账户查最近流水，两边都不会难看。难看的是“我想顺手统计一下今天状态分布，再按渠道估个峰值”，然后一条 SQL 把过滤、排序、聚合、去重全揉进去。执行计划一上一下，优化器性格就出来了。

SELECT flow_status, COUNT(*) AS cnt, SUM(amount) AS amt
FROM acct_flow
WHERE biz_time >= '2026-09-13 00:00:00'
AND biz_time < '2026-09-14 00:00:00'
GROUP BY flow_status
ORDER BY amt DESC;

这条 SQL 本身不妖。妖的是数据倾斜：N 状态占九成，C 状态很少，索引到底先扫状态还是先扫时间，统计信息稍微不准，计划就会变。金仓这边我会更依赖统计信息新鲜度、索引选择和 hint 纪律；OceanBase 这边还要额外盯分区裁剪、执行节点间数据传输、以及分布式执行把多少行拉来拉去。不是谁一定慢，是慢的价钱不一样：一个可能慢在优化器选路，一个可能慢在分布式数据搬移叠上强一致。

四、复杂 SQL 见真章：多表关联、嵌套子查询、窗口函数

选型评审我最喜欢看复杂 SQL，因为它最接近真实业务。报表、风控、稽核、账期核对，嘴上都说“就跑一次”，真出问题都在这种 SQL 上。为了避免空对空，我造一个典型诉求：按账户汇总当天流水，找出连续充值后余额异常波动、且流水状态非完成的账户，再给出近七日扣费排名。听着绕，实际项目里这算客气。

OceanBase MySQL 租户示意：

SELECT s.sum_date,
s.acct_id,
s.recharge_amt,
s.deduct_amt,
b.balance,
b.frozen_amt,
RANK() OVER (PARTITION BY s.sum_date ORDER BY s.deduct_amt DESC) AS deduct_rank,
COUNT(*) OVER (PARTITION BY s.acct_id ORDER BY s.sum_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS active_days_7
FROM acct_daily_sum s
JOIN acct_balance b
ON b.acct_id = s.acct_id
AND b.balance_date = s.sum_date
WHERE s.sum_date = '2026-09-13'
AND EXISTS (
SELECT 1
FROM acct_flow f
WHERE f.acct_id = s.acct_id
AND f.biz_time >= '2026-09-13 00:00:00'
AND f.biz_time < '2026-09-14 00:00:00'
AND f.flow_status <> 'C'
)
ORDER BY deduct_rank
LIMIT 100;

金仓侧：

SELECT s.sum_date,
s.acct_id,
s.recharge_amt,
s.deduct_amt,
b.balance,
b.frozen_amt,
RANK() OVER (PARTITION BY s.sum_date ORDER BY s.deduct_amt DESC) AS deduct_rank,
COUNT(*) OVER (PARTITION BY s.acct_id ORDER BY s.sum_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS active_days_7
FROM acct_daily_sum s
JOIN acct_balance b
ON b.acct_id = s.acct_id
AND b.balance_date = s.sum_date
WHERE s.sum_date = DATE '2026-09-13'
AND EXISTS (
SELECT 1
FROM acct_flow f
WHERE f.acct_id = s.acct_id
AND f.biz_time >= TIMESTAMP '2026-09-13 00:00:00'
AND f.biz_time < TIMESTAMP '2026-09-14 00:00:00'
AND f.flow_status <> 'C'
)
ORDER BY deduct_rank
FETCH FIRST 100 ROWS ONLY;

两种写法业务目标一致，但你要盯的点不完全一样。金仓这边，我会看嵌套子查询能不能被半连接改写，窗口函数排序是否引发大数据量落盘，JOIN 顺序是不是被统计信息带偏；必要时用 hint 或把 EXISTS 改成显式聚合后回表。OceanBase 这边，除了优化器选择，还要多问一句：这个 JOIN 会不会把数据在不同节点之间搬？窗口函数的分区排序发生在本地还是分布式重分布之后？如果 acct_daily_sum 按日期分区、acct_balance 按账户分区，关联键又跟分区键不齐，数据搬运就不会跟你客气。

我也见过一种“聪明反被聪明误”的写法：为了展示窗口函数，把所有明细都塞进一个巨大子查询，再外层过滤。看起来很高级，执行起来常把中间结果撑爆。复杂 SQL 优化，我宁可让业务承认它其实是两步：先落一张日汇总，再做排名和异常筛选。很多性能问题不是数据库救不了，是 SQL 把自己的胳膊拧到背后，还要求跑得快。

为了说明这个点，再给一版“别硬刚”的写法。先固化日汇总，再跑分析。丑，但稳。

CREATE TABLE acct_risk_snapshot (
snap_date DATE NOT NULL,
acct_id BIGINT NOT NULL,
deduct_rank BIGINT,
active_days_7 BIGINT,
balance NUMERIC(18,2),
frozen_amt NUMERIC(18,2),
CONSTRAINT pk_acct_risk_snapshot PRIMARY KEY (snap_date, acct_id)
);

INSERT INTO acct_risk_snapshot(snap_date, acct_id, deduct_rank, active_days_7, balance, frozen_amt)
SELECT s.sum_date,
s.acct_id,
RANK() OVER (PARTITION BY s.sum_date ORDER BY s.deduct_amt DESC) AS deduct_rank,
COUNT(*) OVER (PARTITION BY s.acct_id ORDER BY s.sum_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS active_days_7,
b.balance,
b.frozen_amt
FROM acct_daily_sum s
JOIN acct_balance b
ON b.acct_id = s.acct_id
AND b.balance_date = s.sum_date
WHERE s.sum_date = DATE '2026-09-13';

SELECT r.*
FROM acct_risk_snapshot r
WHERE r.snap_date = DATE '2026-09-13'
AND EXISTS (
SELECT 1
FROM acct_flow f
WHERE f.acct_id = r.acct_id
AND f.biz_time >= TIMESTAMP '2026-09-13 00:00:00'
AND f.biz_time < TIMESTAMP '2026-09-14 00:00:00'
AND f.flow_status <> 'C'
)
ORDER BY r.deduct_rank
FETCH FIRST 100 ROWS ONLY;

有人会说，快照表是不是作弊？我不这么看。账期、风控、经营分析本来就有批处理属性，把瞬时一致性要求强行套到半小时报表上，才是很多系统又慢又脆的根源。OceanBase 也不是不能扛明细级复杂分析，但你要付出数据重分布和计算资源；金仓也不是只能跑小查询，但超大分析更要靠物化、汇总、索引和任务错峰。选型的 maturity，就看你敢不敢承认：有些 SQL 不该在交易链路里实时硬算。

五、运维成本：宣传页不讲的那部分，才是账单

聊 OceanBaseVS金仓，如果只停在跑分，就太便宜了。上线以后，真正每天烦你的，是变更、备份、故障、扩容、慢 SQL、权限、审计、监控口径，还有半夜那张“核心交易延迟抖动”的告警。

OceanBase 的运维叙事更现代化：节点、副本、分片、资源池、租户，很多动作平台化程度高，扩容思路也更符合“先加机器再说”的直觉。但硬币反面是，你要理解的概念也更多：合并、转储、租户资源隔离、 Paxos 成员变更、跨机房复制、leader 分布、热点调度。团队如果没有分布式基本功，初期会把“平台化了”误听成“不用懂了”。真出问题时，一句“leader 都在另一个机房”就够你清醒。

金仓这类企业库的运维手感，更像长期工程：备份恢复、主备切换、参数基线、慢 SQL 治理、统计信息维护、存储和归档、应用发布窗口，套路成熟，文档和DBA经验也容易沉淀。代价是，当业务量冲得快时，你不能只会“加配置”，要更早准备读写分离、历史归档、分库分表、同步链路，甚至把部分分析流量切走。换句话说，金仓把很多难题留在架构设计阶段；OceanBase 把很多难题收进产品，但仍要求你懂它在收什么。

我做过一个粗糙但实用的对比表，不评优劣，只放评审会上防跑偏。

注意，表里我没有写谁一定赢。因为我真见过 OceanBase 在金融级场景里把高可用做得体面，也见过金仓在政企核心系统里把稳定和运维成本压住。反过来，我也见过团队拿分布式扛一个根本不用分布式的系统，复杂度和延迟双双上升；也见过集中式系统被业务增长拖到极限，才临时抱佛脚做拆分，数据迁移和业务改造挤在同一个窗口，谁看谁头皮发麻。

六、怎么测，才不像互相耍流氓

如果非要我给出测试口径，我会坚持四条。第一，用真实业务模型，不要只跑通用压测。账务就构建热点账户、账期批扣、冲正、幂等重放；订单就构建库存扣减、超时关闭、售后逆向。第二，压延迟分布，不压平均数的虚荣心。P50、P95、P99、P999 都留，热点账户单独一组，跨机房部署单独一组。第三，把同步链路和回放追平时间算进总账。别前台事务很快，后台追了六小时，业务还觉得自己没切完。第四，复杂 SQL 要分“交易内”和“分析型”两类，混着测的结果只能喂饱PPT。

我还会留一组“找茬SQL”：多表关联里故意制造小表驱动大表、大表驱动小表两种写法；嵌套子查询分别用 EXISTS、IN、显式 JOIN 表达；窗口函数分别放在明细上算和落在日汇总上算。每组都看执行计划、逻辑读、临时空间、CPU、网络传输和长尾。很多人测完只记得一个“谁快”，其实更有价值的是：哪类写法在哪边开始失控，失控前有什么信号。这个信号，才值得写进开发规范。

最后补一刀：别忽略人的成本。你团队如果已经有成熟的分布式平台组，OceanBase 的上手曲线会平很多；如果强在一套传统企业库治理、过程化对象、审计合规和稳定运维，金仓的磨合成本也可能低得多。数据库选型最后常常不是技术极限之争，而是组织能力之争。这句话不性感，但很省钱。

结尾

回到开头那个问题：OceanBaseVS金仓，到底怎么选？我现在不太愿意给“终极答案”，更愿意给一个动作：把业务链路画出来，把延迟来源拆开，把复杂 SQL 归类，把增长曲线和故障目标写实，然后分别压测，再谈架构优越感。分布式不是 badges，集中式也不是原罪。真正专业的选型，是知道自己在用哪种代价换哪种确定感。

OceanBase 给你的是把一致性、扩展和高可用打包的现代化路径；金仓给你的是成熟企业库的稳定手感、优化治理和运维确定性。你要买单的，从来不是名字，而是那个在账期凌晨不出事、在评审会上能讲清风险、在扩容前不被增长曲线偷袭的系统。