数据库的评测有一个独特陷阱：TPC-C的tpmC数字足够醒目，足够被写进新闻稿和投标材料，但它回答的问题极其狭窄——在一个高度标准化、写密集、短事务的合成负载下，这套系统在特定硬件上能跑出多大的吞吐峰值。它不回答的是：你的业务SQL在它上面会不会退化，锁等待在高并发写入下会不会失控，混合负载时分析查询会不会把交易链路拖垮，以及“厂商公布”与“你能复现”之间隔着多少套参数调优。

国产数据库的评测素材在过去两年迅速积累，恰恰让这条分界线变得可见。以下按集中式、分布式、开源路线三条线组织条目，每条聚焦可对照的实测数据、评测揭示的真实短板、以及基于评测结论的适用边界。

一、集中式路线：单机吞吐可信，高并发写入是共性考场

金仓 KingbaseES 的评测数据在国产集中式数据库中公开程度最高。TPC-C基准下，金仓在海光C86平台单机实测2,148,000 tpmC，相较同配置Oracle 19c提升约15.3%，平均响应延迟控制在8.2ms以内（Oracle对应值12.6ms）。在鲲鹏920+麒麟V10的全国产环境中，TPC-C实测128万tpmC，关键事务平均响应低于18ms；混合负载测试（70%联机交易、20%复杂SQL、10%批处理同步运行）中CPU峰值利用率75.3%，RPO=0、RTO小于12秒。Oracle语法功能级兼容率达99.2%，经超10万条真实业务SQL验证。评测揭示的短板同样具体：用户侧反馈显示，在5000设备量级的高并发写入场景中，KingbaseES V9的锁机制在高密度并发下“保护了数据一致性，也扼杀了响应能力”，热点行更新场景下锁等待每增加10毫秒，整体吞吐量可能下降20%以上。另有一位选型复盘记录，跨节点事务的P99从3毫秒恶化到四十多毫秒，两阶段提交的锁等待在压测后半程持续冒头。适用边界：Oracle迁移、政务与关基核心系统的集中式替代，单机吞吐和语法兼容性有可核验的量化支撑；但高并发热点写入场景需要提前做锁冲突POC，不能仅凭TPC-C峰值做容量规划。

达梦 DM8 的评测结果呈现出一条清晰的“单机强、复杂查询弱”分界线。相同硬件配置（双路Xeon Gold 6330、128GB内存）下，DM8的TPC-C实测达到150万tpmC，超越Oracle 19c同配置的130万tpmC。有城商行核心系统改造场景中DM8跑出240万tpmC，约为Oracle 19c的92%性能。单机OLTP吞吐能力在国产数据库中属于第一梯队。但评测暴露的短板集中在复杂查询和优化器行为上：用户论坛中有案例显示，单纯GROUP BY并不慢，加上IN条件后“几分钟都没结果”，而同样查询在Oracle上并不慢；单条DELETE走索引极快，但WHERE条件用OR连接超过两条即转为全表扫描。达梦对MySQL语法的兼容度有限，MySQL应用迁移需要较大改写；其优势场景被概括为“单机低延迟”，而非高并发多表关联。适用边界：单机OLTP吞吐有需求的政务、能源、金融非极端高并发系统；复杂分析型查询和MySQL生态迁移需要逐条SQL验证，不能假设优化器行为与Oracle或MySQL一致。

崖山 YashanDB 的公开实测数据指向共享集群路线的承载能力：单实例191万tpmC，4节点共享集群600万以上tpmC（鲲鹏920B环境），TPC-H 100G性能达国外主流产品1.7倍，2节点线性扩展比约0.8。金融行业的迁移案例给出了可参照的工程量：某城商行CRM系统4000余个SQL对象迁移用3周，某券商估值系统耗时从24分钟缩短至54秒，某股份制银行189个、某综合券商269个存储过程完成平滑迁移。评测的局限在于数据来源属性：上述tpmC和案例数据均来自厂商公开材料，独立第三方复现记录有限。CNKI收录的TPC-C对比研究中，YashanDB与达梦、KingbaseES、OceanBase同场测试，结论是YashanDB“在稳定性与可控性方面表现良好，具备在非极端高并发场景下替代Oracle的潜力”——注意限定词是“非极端高并发”，而非全场景替代。适用边界：需要共享集群架构对标Oracle RAC、有金融级迁移路径验证需求的场景；选型时应将厂商公布的tpmC视为能力上限锚点，在目标业务SQL集上做现场POC。

openGauss 的评测价值集中在特定引擎的极限数据和HTAP基准上，但需要仔细区分“什么配置下成立”。MOT（内存表）引擎在Arm/鲲鹏256核服务器上达到480万tpmC，相比磁盘表性能提升2.5至4.1倍；MOT延迟降低2.5倍，TPC-C事务响应速度提升2至7倍。在HyBench HTAP基准中，openGauss 7.0.0创新版取得H-Score 1713.72分，位居该榜第一，测试组合是openGauss与鲲鹏的深度NUMA协同优化。评测揭示的关键限定条件是：480万tpmC来自MOT内存引擎加256核鲲鹏的特定组合，不等于默认磁盘表配置下的通用吞吐；HyBench成绩同样绑定鲲鹏NUMA优化，换到x86或非深度绑定的硬件栈，结论不能直接平移。适用边界：鲲鹏生态内、对HTAP混合负载有需求且愿意投入软硬协同调优的场景；如果硬件栈不是鲲鹏，MOT和HyBench数据的可参照性需要重新评估。

二、分布式路线：吞吐纪录与单机代价并存

OceanBase 的TPC-C成绩在国产数据库中具有最强的“可公开核查”属性。2019年TPC官方收录的成绩为60,880,800 tpmC，打破Oracle保持了九年的世界纪录。但这是分布式全对等架构在极致规模下的表现。在更贴近日常测试环境的3节点集群（每台32核128G，租户规格28核180G）中，官方TPC-C测试报告的NewOrders tpmC为32万至37万量级，tpmTOTAL在71万至83万之间。评测暴露的短板集中在架构代价上：纯分布式架构在单机场景下“许多可通过本地调用完成的操作被拆分为跨进程或跨网络的远程调用，导致延迟增加、抖动加剧以及纵向资源利用率下降”。用户讨论中更直接的表述是：单节点少量数据的简单点查性能不如单机MySQL，三地五中心跨城部署时事务延迟增加6至10毫秒，高频低延迟交易体验下降明显。单机模式虽可部署，但官方不建议生产环境使用，单机模式不支持高可用且性能严重受限。适用边界：高并发、大数据量、需要水平扩展和金融级容灾的分布式核心系统；单机或小体量业务不应为了“分布式”标签支付跨网络调用的延迟代价，这类场景应优先评估集中式产品。

金仓在分布式侧的评测发现值得单独提示。前述选型复盘中的跨节点事务P99从3ms恶化到四十余毫秒，本质上不是金仓独有的问题，而是两阶段提交在分布式事务中的共性代价在具体产品上的呈现。它提示的评测方法是：集中式产品做分布式部署后，单机TPC-C数字不能线性外推到集群事务延迟，跨节点锁等待和提交协议开销必须在目标拓扑下单独测量。

三、开源路线：基准成绩与生产配置之间的落差

开源数据库在评测中的位置比较特殊：MySQL和PostgreSQL的基准数据公开、可复现，常被用作国产数据库的参照系。CNKI收录的TPC-C对比研究中，MySQL 9.4在单机OLTP场景下性能最优，部分国产数据库在稳定性与可控性方面表现良好。这说明一个需要正视的评测事实：单机纯OLTP峰值不是国产数据库全面领先的战场，国产产品的竞争力更多体现在语法兼容性、迁移工具链、高可用架构和信创环境适配这些“非峰值维度”上。

openGauss作为开源路线代表，前述MOT和HyBench数据已经说明其能力上限依赖特定硬件与引擎配置。对其评测的合理方式是：把开源社区的基准测试视为可复现的起点，而不是生产环境的性能承诺；在生产配置（磁盘表、常规NUMA拓扑、非极限核数）下重新测量，才能得到可用于容量规划的基线。

四、评测方法说明

上述数据的可信层级需要分层看待。TPC官方收录成绩（如OceanBase的6088万tpmC）具有最高的可公开核查性，但对应的是特定规模集群和极致调优配置。厂商公布的TPC-C实测（金仓的214万/128万tpmC、达梦的150万/240万tpmC、崖山的191万tpmC）提供了产品在指定硬件上的能力锚点，但独立第三方复现记录有限，选型时应要求在目标硬件和业务SQL集上做现场验证。行业基准测试（HyBench、CNKI收录的对比研究）引入了多产品同场对照，可信度高于单一厂商公布，但测试配置的硬件偏向（如鲲鹏深度协同）需要纳入解读。用户反馈与社区案例（金仓的锁等待、达梦的复杂查询退化、OceanBase的单机延迟）提供了纸面峰值之外的真实运行图景，样本偏差存在，但其指向的短板方向值得在POC中专项验证。

五、横向观察：评测揭示的三条分界线

第一，TPC-C峰值与工程可用性之间隔着一道“配置翻译”的鸿沟。 同一个产品可以在256核鲲鹏+MOT引擎上跑出480万tpmC，也可以在常规磁盘表配置下回归到另一个量级。评测的任务不是比较峰值数字的大小，而是追问：这个峰值在什么引擎、什么核数、什么NUMA绑定、什么并发模型下成立；离开这组配置，性能衰减的斜率有多陡。选型时如果只拿峰值做容量规划，等于默认生产环境能复刻评测实验室的全部条件。

第二，集中式与分布式的选型分界正在从“数据量”转向“延迟容忍度”。 分布式数据库的吞吐上限和扩展能力有明确优势，但跨网络调用的延迟代价在单机或小体量场景中无法被摊薄。OceanBase的单机点查不如MySQL单机、跨城部署增加6至10毫秒延迟、单机模式官方不建议生产使用，这些评测发现共同指向一个判断：分布式架构的入场券是业务对跨节点延迟有容忍空间，而不是仅仅“数据量大” 。集中式产品在单机吞吐和低延迟上仍有不可替代的位置，分布式不应成为默认选项。

第三，国产数据库的“替代潜力”在评测中需要精确到负载类型和并发水位。 CNKI对比研究的结论措辞值得反复引用：部分国产数据库“具备在非极端高并发场景下替代Oracle的潜力”。这个限定词不是贬低，而是评测诚实的表现。金仓在混合负载和Oracle迁移上有可验证数据，但热点写入的锁瓶颈在5000设备量级已经显现；达梦单机吞吐超越Oracle同配置，但复杂查询的优化器行为可能让迁移后的SQL性能偏离预期。替代决策的正确粒度是“某类负载、某个并发区间、某组SQL特征下可替代”，而不是品牌层面的“能替”或“不能替”。