“互联网经济”所带来的巨大流量使得企业、机构面临外部访问负载以及数据量的大幅飙升，很多企业信息系统目前所采用的传统集中式关系型数据库越来越不适应海量数据以及高并发环境下对数据处理能力的要求，在应对此类场景时数据库逐渐成为整体系统的瓶颈，扩展成本较高。
为了解决这些问题，互联网企业最先进行了尝试和探索，他们采用分库、分表，使用 MySQL+数据库中间件方案来解决问题，我们把这种方案称作 "第二代分布式数据库方案"，简称 "二代方案" 。另一种解决问题的方法是基于分布式计算理论、算法和新的技术，采用新的架构设计，吸收了关系型数据库和NoSQL数据库各自的优点 ，创建新一代分布式关系型数据库从根本上加以解决，有人把它称作New SQL数据库。我们把这种New SQL数据库称作 "第三代分布式关系型数据库"，简称 "三代库" 。
无论是二代方案还是三代库，他们的初衷是相同的，都是为了解决传统关系型数据库扩展能力问题的。在下面的内容中，将给出优先选择三代库的理由。
1. 社会经济发展趋势决定
近些年，互联网、移动互联网、云计算、大数据和人工智能等技术飞速发展，已经渗透到社会经济的各个领域，给各行业乃至整个国家的经济结构带来了深刻的影响和变革。未来，互联网经济体系一定会成为社会经济的主流。
“互联网经济”带来的巨大流量使得企业、机构面临的外部访问负载以及数据量大幅提升，这使得企事业单位的IT架构、基础设施以及应用系统等都面临着变革。作为系统核心资源的“关系型数据库”也要适应和满足这种发展趋势带来的影响和挑战，用“新的架构”和“新的技术”进行升级换代。
2. 技术发展趋势决定
在“互联网经济”下，“分布式数据库”是数据库发展的大势所趋。“分布式数据库”能够显著提升大容量数据的存储和管理能力，既能够满足大量用户的高并发访问需求，又能够保障面对业务变化的弹性扩展能力。
目前全球顶尖的数据库厂商，都在设计研发和推广第三代分布式关系数据库，它可以彻底解决第二代分布式数据库方案在关键计算领域难以突破的困境。
3. 技术优势决定
为了解决传统关系型数据库在高并发支持和扩展能力等方面的瓶颈，互联网企业引入并逐渐完善了 "二代库方案" 。这种方案能够比较好地满足互联网企业自身的业务需求，但是它不是为金融业务场景打造的，无法实现对应用透明的金融级分布式交易事务；无法在不影响应用的情况下完成弹性伸缩；应用开发的难度较高、运维工作的挑战较大。
“第三代分布式关系数据库”无须中间件，在数据库引擎上通过先进的架构、工程设计和算法，能够满足金融行业对高可用、高可靠、高扩展能力的苛刻要求。能够在对业务无影响、无制约的情况下，实现自动地、可靠地强一致性和完备的分布式事务处理。
下表是二代方案和三代库的主要技术特性对比：
| 对比条目 |
二代库分布式数据库方案 |
三代库 |
| 易用性 |
低 |
高 |
| 强一致性分布式事务 |
部分支持 |
支持(引擎内置) |
| 水平扩展 |
人工操作 |
支持(引擎内置) |
| 复杂查询（JOIN/GROUP BY/子查询） |
部分支持 |
支持(引擎内置) |
| 无人工介入的高可用 |
不支持 |
支持(引擎内置) |
| 业务灵活性 |
低 |
高 |
| 应用开发透明性 |
低 |
高 |
| 开发和运维成本 |
高 |
低 |
4.成本和风险决定
在现阶段新的金融类项目中如果考虑二代方案，将会面临三个风险：
(1) 技术滞后风险
二代方案虽然也采用了分布式架构，但是它的出发点是基于已有的数据库产品进行改良，因此其采用的设计、算法和技术都是围绕着改良进行的。我们认为，二代方案是一种“中间过渡”产品，未来不会是主流。
(2)业务场景受限的风险
二代方案可能仅限于某些安全等级低，且和金融相关业务关系不大，业务代码可以随意调整的类互联网/电商类业务场景。
(3)较高的开发和运维成本风险
互联网公司背后有大量的数据库相关的运维专家和人力投入以支持二代架构的开发和运维，这不是传统企业的技术体制和人力资源池能够轻松支撑的。