1、金融行业数据库选型概述

各位同学好，我是老张。今天咱们聊聊金融数据库选型这件事。说实话，我在这个领域摸爬滚打了十几年，踩过的坑比走过的路还多。金融业务对数据库的要求，说白了就三个字：稳、准、狠——稳定不能丢数据，准确不能算错账，狠起来性能要扛得住秒杀。

金融业务对数据库的核心需求

先说说金融业务到底要什么。我参与过银行核心系统迁移，也做过证券交易库的选型。总结下来，核心需求就这四点：

• ACID 事务：转账扣款必须原子性。你想想看，A 转给 B 100 万，A 扣了钱 B 没收到，这谁受得了？
• 高可用：金融系统停机一分钟，损失可能就是几百万。我记得某次券商交易系统宕机 10 分钟，客户直接投诉到证监会。
• 数据一致性：尤其是跨库、跨分片场景。我曾经在项目中遇到过，因为最终一致性导致对账不平，运维同学通宵排查。
• 安全合规：监管要求数据不能丢，审计日志不能少。嗯，这块很多同学容易忽略。

主流数据库分类

现在市面上的数据库，我习惯分成三大类。咱们一个一个看：

关系型数据库（RDBMS）

这类数据库，说白了就是传统派。Oracle、MySQL、PostgreSQL 是主力。金融核心系统里，Oracle 还是老大哥。为什么？因为它的 RAC 和 Data Guard 太成熟了。我做过一个银行核心库，Oracle 跑 8 年没出过事故。

MySQL 呢？互联网公司用得多。但金融场景要注意——MySQL 的 binlog 复制是异步的，主库挂了可能有数据丢失。我建议金融核心场景用 MySQL 的话，一定要配半同步复制或者 Group Replication。

PostgreSQL 最近很火。它的 MVCC 实现比 MySQL 干净，而且支持窗口函数、CTE 这些高级特性。我有个项目用 PG 做风控系统，复杂查询性能比 MySQL 好 3 倍。

NoSQL 数据库

NoSQL 不是「没有 SQL」，而是「Not Only SQL」。金融场景里，NoSQL 主要用在非核心业务：

• Redis：缓存、计数器、分布式锁。秒杀场景必备。
• MongoDB：日志存储、用户画像。我建议别用它做主库，因为事务支持太弱。
• HBase：海量时序数据。比如交易流水归档，查询效率很高。

NewSQL 数据库

NewSQL 是新生代，想同时搞定 ACID 和水平扩展。代表产品有 TiDB、OceanBase、CockroachDB。我最近在帮一家支付公司做选型，TiDB 的弹性扩缩容确实香。但要注意——NewSQL 的分布式事务开销不小，跨节点事务多了性能会下降。

类型	代表产品	适用场景	我的建议
关系型	Oracle、MySQL、PG	核心交易、账务系统	核心首选 Oracle，互联网用 MySQL
NoSQL	Redis、MongoDB、HBase	缓存、日志、画像	别做主库，只做辅助
NewSQL	TiDB、OceanBase	高并发、弹性扩展	适合新系统，迁移成本高

选型决策树与评估框架

说了这么多，到底怎么选？我总结了一套决策树，你照着走就行：

1. 业务类型：核心交易？走关系型。日志分析？考虑 NoSQL。高并发写入？看看 NewSQL。
2. 一致性要求：强一致性？必须 ACID。最终一致性？可以放宽。
3. 扩展需求：未来 3 年数据量翻 10 倍？NewSQL 或分库分表。
4. 运维能力：团队有 DBA 吗？没有的话，选托管服务或者 NewSQL。
5. 成本预算：Oracle 贵但稳，MySQL 免费但需要人。自己算账。

下面这张图是我自己画的选型决策流程，你参考一下：

最后说说评估框架。我一般用这 6 个维度：

• 功能完整性：SQL 支持、事务、索引、分区
• 性能：TPS、QPS、延迟 P99
• 高可用：RPO、RTO、故障切换机制
• 扩展性：水平扩展、垂直扩展、在线扩缩容
• 生态工具：监控、备份、迁移工具
• 成本：License、硬件、运维人力

好了，这一章就到这里。记住：选型没有银弹，只有最适合你业务场景的方案。下一章咱们聊聊具体的迁移策略，到时候我会分享一个真实的银行核心库迁移案例，保证让你少走弯路。

---

公众号:蓝海资料掘金营，微信deep3321