国产数据库的金融实践：从“外围替代”到“核心账本”

金融行业是国产数据库最早、也最挑剔的试验场。2020 年，人民银行发布 JR/T 0203-2020《分布式数据库技术金融应用规范技术架构》、JR/T 0204-2020《安全技术要求》和 JR/T 0205-2020《灾难恢复要求》，把分布式数据库的技术架构、安全和容灾要求写成了行业标准。此后，国产数据库从外围系统、中间业务一路走到核心账本，讨论的重点也从“能不能用”转向“能不能稳”。

一、三条曲线：从外围到核心，从兼容到稳定

北京金融科技产业联盟 2023 年发布的《分布式数据库金融应用发展报告》给出了一个清晰的分层：76% 的金融机构已经采用分布式数据库，56% 是存量系统迁移、44% 是新建系统；从业务类型看，中间业务占 67%，资产业务占 22%，负债业务占 11%；核心系统渗透率约 6%。报告调研时的平均迁移周期约 6.5 个月，约 75% 的核心业务数据库仍部署在本地物理服务器，同城双活是最主要的容灾模式，金融级要求普遍是 RTO 不超过 30 分钟、RPO 等于 0。

这组数据说明了两件事。第一，国产数据库已经跨过“能不能跑”的门槛，中间业务和外围系统是最先规模化落地的场景。第二，核心系统仍是少数派，2023 年的 6% 不是失败，而是核心系统对一致性、可用性、性能和运维的要求远高于外围系统。此后两年，核心案例明显增加，但“核心账本”仍然是国产数据库最难、也最有说服力的一块阵地。

从市场看，中国信通院《数据库发展研究报告（2025 年）》显示，2024 年中国数据库市场规模约 596.16 亿元，预计 2027 年达到 837.42 亿元；截至 2025 年 6 月，中国数据库厂商 103 家、产品 164 款，产业正在从“数量型”转向“质量型”。厂商数量多、产品迭代快，意味着选型不能只看排名，更要看版本路线、生态工具和本地服务能力。

二、效果已经出现：三个公开案例

邮储银行：openGauss 与鲲鹏承载 6.5 亿用户

邮储银行新一代个人业务核心系统基于鲲鹏和 openGauss，2022 年 4 月上线。公开资料显示，系统服务 6.5 亿用户、日交易量 20 亿笔，峰值 TPS 提升 319%，峰值达到 6.7 万笔/秒；平均联机交易耗时 65 毫秒，下降约 30%；季度结息时间从 140 分钟降到 35 分钟。这个案例的意义不只是性能数字，而是证明了分布式核心系统可以在国有大行的业务体量下稳定运行。

瑞众保险：8 个月完成 Oracle 到 TDSQL 的团险核心迁移

瑞众保险团险核心系统在 2025 年 10 月完成 Oracle 到腾讯云 TDSQL 的迁移并投产。厂商公开信息显示，项目历时约 8 个月，涉及 3000 多个数据库对象、80 万条以上 SQL，Oracle 语法兼容度 99.4%；上线后整体性能提升约 20%，批量处理效率提升约 25%，数据库相关软硬件成本下降约 40%，实现 RPO=0、RTO 小于 30 秒。这个案例说明，保险行业的核心系统也可以在不长时间停机的前提下完成数据库替换。

国家开发银行：资金系统的国产化与容灾

国家开发银行资金系统历时两年完成基础软硬件国产化，2025 年 10 月新系统投产。公开案例显示，OceanBase 对常见功能的兼容性达到 95% 以上，全量业务数据压缩备份降至原来的 1/8，生产与同城灾备保持实时同步。对资金类系统而言，数据一致性和灾备能力比单点性能更重要，这个案例的价值在于把“国产数据库能不能承载资金业务”从讨论变成了运行记录。

需要说明的是，这些数字来自厂商或公开案例，测试基线、硬件配置、业务模型并不相同，不能简单横向比较。它们能证明“路径可行”，不能证明“每个机构都能复制同样的提升幅度”。

三、真实门槛：最后 1% 的兼容性，分布式事务与运维

1. 兼容性不是 99% 就够

99.4% 的 Oracle 语法兼容度听起来很高，但放到 80 万条 SQL、3000 多个数据库对象里，剩下的 0.6% 仍可能是几千条需要人工复核的语句。更麻烦的是优化器行为、执行计划、锁机制、事务隔离和存储过程语义，这些不是语法转换工具能完全解决的。

核心系统迁移前，应该做一次“对象级”兼容性盘点：SQL、PL/SQL、存储过程、触发器、序列、分区、索引、字符集、时区、空值语义，逐项标注“自动转换、人工改写、需要应用改造、暂不支持”。POC 要用真实业务峰值，而不是只跑 TPCC 一类的基准。

2. 分布式事务会改变应用设计

分布式数据库不是把单机库换成多个节点那么简单。分区键怎么选、跨分片事务怎么处理、全局一致性怎么保证、单元化架构怎么划分，都会影响应用设计。很多项目在数据库层完成了迁移，却在应用层留下了跨库 JOIN、全局唯一序列、长事务和批量更新等隐患。

行业里比较稳妥的做法是：先做应用改造评估，再做数据库迁移；把跨分片事务、热点账户、批量作业和月末结算作为专项验证；不要用“数据库兼容”掩盖“应用不兼容”。

3. 双轨运行与数据校验不能省

报告调研的平均迁移周期约 6.5 个月，核心系统通常更长。双轨运行不是简单地把数据同步过去，而是要验证三件事：数据一致性、性能可接受、运维流程可执行。

双轨期至少要覆盖一次月末、一次季末和一次年终结算；要有全量加增量的数据比对、差异定位和反向同步方案；要明确什么条件下回退、谁来决策、回退后如何追平数据。跳过双轨直接切流，是核心系统迁移中最危险的动作之一。

4. 性能与成本要看真实账本

厂商案例里的 TPS 提升、成本下降，通常对应特定的硬件和业务模型。真实 TCO 至少要算五块：数据库许可、服务器与存储、迁移与改造人力、运维工具、容灾与备份。分布式数据库还可能带来网络、监控、培训和机房资源的额外投入。

性能也要看业务账，而不是只看峰值 TPS：联机交易的 P99 时延、批量窗口、月末结算、报表查询、故障切换时间，才是业务部门真正感知的指标。

5. 运维与人才是长期门槛

分布式数据库的运维与单机库不同：节点管理、分片扩容、全局监控、备份恢复、版本升级、故障定位，都需要新的工具和技能。行业报告普遍把运维复杂度列为金融应用的主要挑战之一；两年后，工具链有所成熟，但“会装不会调、能跑不敢升”仍然是常见状态。

选型时要把原厂支持、社区活跃度、文档质量、培训与认证、本地服务能力放进评分表。核心系统不是一锤子买卖，数据库上线后的每一次版本升级、每一次故障处理，都是对生态的考验。

四、选型与落地清单

按业务类型分级：外围、中间业务、核心账本分别设定迁移策略和验收标准。
做对象级兼容性盘点，量化 SQL、存储过程和应用改造量。
用真实峰值做 POC，验证 P99 时延、批量窗口、故障切换和灾备切换。
设计双轨运行和数据校验方案，覆盖月末、季末和年终结算。
把分布式事务、分区键、热点账户和单元化架构纳入应用改造评估。
提前建设监控、备份、容灾、SQL 治理和人才培养体系。
保留回退路径，明确回退条件和数据追平方案。

结语

国产数据库在金融行业的实践，已经走过了“能不能用”的阶段。邮储银行、瑞众保险、国家开发银行等公开案例证明，核心系统可以跑在国产数据库上，而且能跑出性能、成本和可用性的收益。

但核心账本的竞争，最终不是产品功能的竞争，而是工程纪律的竞争：兼容性评估是否彻底、双轨运行是否真实、数据校验是否可复核、运维体系是否接得住。2023 年报告里的 6% 核心渗透率，说明这条路还很长；公开案例里的成功，说明这条路已经有人走通。