作为金融业务的技术负责人，在数据库选型过程中，我们对 GoldenDB、OceanBase、GBase、GaussDB 和 TiDB 进行了深入的调研与评估。最终选择 TiDB 作为核心业务数据库，主要基于以下几个关键维度的综合考量：
一、核心选型原因
- 真正的分布式架构，原生支持水平扩展
TiDB 是原生分布式 NewSQL 数据库，采用计算（TiDB）、存储（TiKV）、调度（PD）三层分离架构。
相比之下：
GoldenDB 虽为金融级分布式数据库，但依赖特定硬件和定制化部署，生态封闭；
OceanBase 虽性能优异，但早期版本对 Oracle 兼容性较强，MySQL 模式存在功能限制，且社区版功能阉割较多；
GBase 和 GaussDB 多为集中式或伪分布式架构，在高并发、海量数据场景下扩展性受限。
TiDB 可以通过简单增加节点实现线性扩容，非常适合未来业务快速增长的需求。 - 强一致性与高可用保障
TiDB 基于 Raft 协议 实现多副本强一致性，RPO=0、RTO<30秒，满足金融级容灾要求。
所有节点无单点故障，自动故障转移，运维成本低。
对比来看，部分国产数据库（如早期 GBase）在跨机房容灾和自动切换方面仍需人工干预。 - 高度兼容 MySQL 生态
TiDB 高度兼容 MySQL 5.7 协议和语法，现有应用几乎无需改造即可迁移。
开发者、DBA 工具链（如 Navicat、MyBatis、Percona Toolkit）可直接复用。
而 OceanBase 的 MySQL 模式在复杂查询、窗口函数、JSON 支持等方面仍有差距；GaussDB 虽兼容 PostgreSQL，但团队技术栈以 MySQL 为主，迁移成本高。 - HTAP 能力：实时分析与交易一体化
TiDB 4.0+ 引入 TiFlash 列式存储引擎，实现一份数据同时支持 OLTP 和 OLAP（HTAP）。
金融场景中，风控、实时报表、反欺诈等需求无需再建数仓，降低架构复杂度和数据延迟。
其他产品如 GoldenDB、GBase 8a 虽有分析能力，但通常需独立集群，数据同步存在延迟。 - 开源开放，社区活跃，避免厂商锁定
TiDB 是 Apache 2.0 开源协议，代码透明，社区活跃（GitHub 35k+ stars），全球用户众多。
我们可自主掌控升级、定制和问题排查，避免被单一厂商绑定。
相比之下，GoldenDB、部分 GaussDB 版本闭源，GBase 社区支持弱，长期维护风险较高。 - 金融行业落地案例成熟
在支付、清算、账务、风控等核心场景有成功实践，验证了其稳定性和合规性。
二、为什么不选其他数据库？
GoldenDB：虽为华为/中兴系金融数据库，但封闭性强、依赖厂商支持，扩展性不如 TiDB 灵活。
OceanBase：性能强，但社区版功能受限，MySQL 兼容性不够“原生”，学习曲线陡峭。
GBase：产品线分散（8a/8s/8c），分布式能力参差不齐，社区和文档支持较弱。
GaussDB：华为主推，但生态偏向 Oracle/PostgreSQL，与我司 MySQL 技术栈不匹配。
在金融业务对稳定性、一致性、扩展性、合规性的严苛要求下，TiDB 凭借开源、分布式、MySQL 兼容、HTAP 一体化的综合优势，成为我们最平衡且面向未来的数据库选择。