阿里巴巴 P3C 规范给出一个推荐：

【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

对于银行业务来说，500 万这个量还是很容易触达的。

分库分表的类型

水平分表：把一个大表数据在同一个库内拆分成多个表，这些表表结构一样，数据没有交集，如下图：

垂直分表：按照字段的维度，把一个大表拆分成多个表，每个表的字段都不一样，如下图：

水平分库：对库中的大表水平拆分到不同的库，最后所有库的表结构完全一样，数据没有交集，如下图：

垂直分库：对库中的大表垂直拆分到不同的库，每个库的表结构都不一样，如下图：

分库的优势:
支持更多的连接数
降低数据库故障影响范围
解决热点数据太多缓存放不下的问题
分库的代价:
跨库查询不支持 join
会有分布式事务问题
聚合函数不能直接使用
自增 id 会有冲突

分库分表中间件

1.TDDL

淘宝的分库分表中间件，基于 JDBC 规范，没有 server，用 client-jar 包依赖的方式部署。

tddl 不支持下面的操作：

• join 语句
• between/and
• not 语句
• for update
• force index 语句
• 数据库内部函数
• 多表查询

下图是 github 上 tddl 现状，可以看到已经停止维护了。

2.kingshard

kingshard 由 go 语言开发，使用时需要安装 go 语言环境和 server，目前快手在用。从 github 上看，近 1 年有维护，但是不多：

缺点：不支持各类 join 和多表查询
优点：拆分表的数量可以跟拆分库的数量不一样，即分库后可以建子表

3.sharding-sphere

前身 sharding-jdbc，目前比较热的一款中间件，好多公司在用。github 上可以看到最近一个月内都有提交代码：

sharding-sphere 使用 jar 包依赖的方式，不需要部署 server。

社区活跃，遇到问题容易得到支持，支持分布式事务

4.Mycat

非常成熟的一款中间件，需要部署 server 做代理。网上吐槽 mycat 的商业味太浓，从 github 看，近期更新比较少。

5.问题

使用分库分表中间件会带来一些问题：

• 不能完全兼容原生 sql
• 业务代码改动非常大
• 部署 server 的中间件需要考虑高可用
• 实际开发中可能会遇到各种坑

分布式数据库

分布式数据库是近几年兴起的新型数据库，主流的分布式数据库有 2 类，一类是 PGXC 风格的，另一个是 NewSQL 风格的。多数分库分表对 mysql 的语法支持更好一些，对 oracle 语法不太兼容。

PGXC 风格的数据库，是在传统关系型数据库分片集群之上，增加了协调节点和全局事务管理器(GTM)来实现对分布式事务的支持。下面这个图是基于 mysql 单体数据库改进的 PGXC 数据库模型：

而 NewSQL 是由 NoSQL 键值数据库发展而来，构建在 BigTable 上的分布式数据库，不仅具有 NoSQL 对海量数据的存储管理能力，还保持了传统数据库支持 ACID 事务和 SQL 等特性。它主要有以下特性：

• 放弃了 PGXC 架构中单体数据库的事务
• 在 BigTable 基础上构建了事务支持
• 引入分片机制，主要采用 Range 动态分片技术，跟 HASH 分片相比，数据可以不用固定的在某一个分片上
• 可靠性方面，放弃传统数据库的主从复制，采用 Paxos、Raft 等共识算法来保证 HA
• 存储引擎方面，使用 LSM-Tree 替换 B+树模型，写入性能更高

下面这张思维导图分享了主流分布式数据库，左边的 5 款是主流的 PGXC 风格数据库，右边的 6 款是 NewSQL 数据库。

使用分布式数据库的优势：

• 解决了分布式事务问题
• 实现了强一致要求
• 技术新潮流
• 解决数据库国产化诉求

使用分布式数据库的挑战：

• DBA 团队运维能力
• 业务代码的改动量
• 新技术可能带来的坑
• sql 不兼容问题

oracle 分区表

如果当下使用的是 oracle 数据库，解决数据量太大带来的性能问题，oracle 的分区表是非常不错的选择。

oracle 分区表有以下几种类型：
范围分区：根据 id 或者时间进行范围分表
列表分区：表中的某个字段有固定几个值，使用这个值做分表
HASH 分区：使用 HASH 函数做分区，分区表数据比较均匀
组合分区：可以使用上面的 2 种做组合分区

使用 oracle 分区表的优势：

• 没有 sql 不兼容问题
• 业务代码改动较小
• 不需要考虑分布式事务
• DBA 团队运维压力小

使用 oracle 分区表的考虑：

• 技术偏保守
• 不能满足国产化诉求
• 不利于长远去 o 计划

系统单元化改造

除了上面提到的分库分表技术外，也可以使用系统单元化的方式来完成。这个做法有下面几个方面需要考虑：

• 是否支持动态分库分表
• 是否要考虑分布式事务中间件
• 多个系统的分库分表代码抽象共用

系统单元化改造，对 DBA 的运维压力小，但是对于开发团队来说不光当下工作量巨大，以后去 o 或者分布式技术的引入都会有巨大的改造量。

银行使用现状

工商银行

目前主要使用 mysql 和分库分表中间件(DBLE)，联合华为研发 GaussDB 200 并且部分系统投产使用。

邮储银行

老系统依然采用 oracle，新系统逐步过渡到 PostgreSQL，没有使用分库分表中间件和分布式数据库。应对大数据量带来的性能问题，邮储银行使用业务系统单元化方式进行改造。

中信银行

联合中兴通讯研发了 PGXC 风格的分布式数据库 GoldenDB，并且部分系统已经投产使用。

交通银行

联合华东师范大学和西北工业大学，研发了 NewSQL 风格的数据库 CBASE，目前已经应用到多个核心交易系统中。

下面的引用出自论文《分布式数据库在金融应用场景中的探索与实践》

数据库属于系统底层核心组件，且分布式数据库技术存在大量的技术难点，此前金融领域也没有相关案例，因此在应用与实践过程中，交通银行遵循“稳定第一、谨慎试点、稳步推广”的原则，先后在金融行业查询类业务、流程类业务和高并发类业务中逐步推广应用，试点均取得了良好的效果，节省了大量的成本.

北京银行

目前有几套重要的实时交易类系统已经对接 TiDB，包括比较重要网联系统、银联无卡支付、金融互联服务平台等。

中国银行

在 Zabbix 监控系统中使用了 TiDB。

光大银行

在云缴费系统中使用了分库分表，而在现金理财业务中使用了 TiDB。

招商银行

下面介绍来自 OceanBase 官网：

基于 OceanBase 的”历史收益系统”已正式上线对外提供服务。通过使用 OceanBase 提供的分区表功能达成了业务无入侵的目标，同时满足业务并发海量数据访问的性能要求。此外，依托 OceanBase 优秀的存储架构和压缩能力在数据存储成本节省方面相比原传统数据库收益显著。目前业务仍在持续迭代，为招商证券相关手机端用户提供在线盈亏分析等特色增值服务。

总结

近几年银行业越来越重视技术的投入，各大行都成立了科技研发中心并且研发投入在持续加大。但银行的技术依然比较传统，数据库使用 Oracle 和 DB2 居多。这不光是技术问题，更重要的是银行业对稳定性的要求太高。

目前头部几家大银行应对大数据量带来的性能问题，手段不尽相同。大部分偏保守，有的银行在一些交易系统、管理系统上引入了分布式数据库和分库分表中间件。

从技术上看，分库分表中间件需要从开发层面解决分布式事务问题，分布式数据库才是未来的主流趋势。

账务核算这类的核心系统，对稳定性和一致性要求几近苛刻，大家在技术选型上都比较保守。至今还没有一家银行愿意在这类系统引入分布式数据库。

对于使用 oracle 的银行，如果不考虑将来去 o，oracle 分区表是最好的选择，因为支持原生 sql，业务代码改动小，不用考虑分布式事务。

有的银行使用业务系统单元化的方式来解决海量数据造成的性能问题，这很好地避开分布式带来的技术挑战，但是业务系统改造工作量巨大，而且对以后技术升级或国产化支持非常不利。

未来银行业在技术上的持续投入必然带来技术的更新换代，而在国产化诉求下，去 o 是必然趋势，相信未来必然会有银行在账务核算类的核心系统中尝试分布式数据库。