观点 | 用 MySQL 数据库，到底会不会被“卡脖子”？

用 MySQL 数据库，到底会不会被“卡脖子”/strong>

在近期不明朗的贸易形势下，一些正在规划数据库选型、迁移的用户，纷纷询问我们对 MySQL 未来前景的看法。那么使用 MySQL 数据库会出现被“卡脖子”的情况吗/p>

下面我将从中美当前的一些文件条例以及数据库技术架构本身的角度为大家进行解答。

商业风险（美方角度）：

Oracle 公司的数据库产品中，多数产品受美国出口管控条例（Export Administration Regulations，EAR）管控，Oracle 官方已在今年 8 月更新了其产品对应的出口管控类别编码（Export Control Classification Number，ECCN，这里关于 ECCN 的背景和分类我们不展开描述）。

其中，对于 Oracle 数据库产品线（Oracle 10g 以及以上版本）以及其他配套软件工具均在 5D992.C 类别中。对于 MySQL 产品线，MySQL 企业版、MySQL 标准版、MySQL 经典版、MySQL 集群版以及 MySQL 嵌入式版同样在 5D992.C 类别中，然而，在 Oracle 提供的表单中，并没有 MySQL 区版（MySQL Community Edition）的记录。

这个时候问题来了，MySQL 项目以及整个开源生态发展到今天，其中关系早已是，你中有我，我中有你，MySQL 中就包含大量第三方组件，这些组件有些作为功能合入了主版本，如我们今天使用的半同步复制源于 Google；而有些组件则作为软件包合入并保留了原有 license，如 innodb 默认使用的异步调用包 libaio。那么如果这些组件受到 EAR 管控怎么办时候 MySQL 区版是否还能和 EAR “划清界限”/p>

由于 MySQL 中涉及的第三方软件太多并且存在持续增加的可能，关于这点我们不能完全给出肯定，但是，我们特别查找了关于出口加密软件源码在 EAR(734.17) 中的描述。由于加密软件与通信安全相关，其管控力度有别于普通软件，在一定程度上可作为边界进行对比参考。（这里关于加密软件为何特殊的缘由我们不展开描述）。

https://www.ecfr.gov/cgi-bin/text-idxID=00a8f54989eaf101a84eff3db59ac6e9&mc=true&node=se15.2.742_115&rgn=div88

商业风险（中方角度）：

阐述完美方的文件条例，下面我们对国内的趋势性文件做一个简单的说明。2017 年，工业和信息化部和国家发展改革委两部委正式印发了《信息产业发展指南》，文件中提出**“支持开源、开放的开发模式，重点推进云操作系统、云中间件、新型数据库管理系统”。**

http://www.miit.gov.cn/n1146295/n1652858/n1652930/n3757016/c5464809/content.html

这表示，开源模式在基础软件的发展中已得到认可，近几年 MySQL 在中大型终端用户群体中，除了应用的规模外，应用的深度也在不断发展，越来越多的非互联 行业用户开始走开源 + 自主管理的整体发展模式，这也使 MySQL 数据库的生态环境不断丰富成熟，因此，从近几年金融、电信等行业的建设成果看，使用 MySQL 并不存在政策风险。

综上所述，当前环境下，不论从中方或是美方政策视角出发，选择 MySQL 区版数据库，不会存在商业上的风险。

技术可行性（ RTO/RPO 可用性级别）：

最后，从技术架构角度，以 Oracle RAC 为代表的商业数据库高可用，通常与存储设备一同部署，由中高端双（多）控制器磁盘阵列充当数据的保险箱，因此 RAC 架构是将数据库的风险转移到存储设备，增强了系统故障中的短板（磁盘），本质上是提升了单点抵抗故障的能力，但局部单点故障仍存在。

而 MySQL 高可用架构，如主从复制/组复制，则采用一主多从模式，将一份数据保留到多个位置（银行业通常采用本地 1 主 1 从 + 同城 2 从的共 4 个库组成数据库高可用组），本质上是利用数据冗余换取更高概率的数据安全，做到避免单点故障。（关于主从复制与组复制和 Oracle RAC 的对比我们不展开讨论）。

因此，在架构得当、运维规范的前提下，MySQL 的高可用机制也能提供金融级的保障能力，同时，对于以上高可用功能，MySQL 区版与 MySQL 企业版完全一致，能够在不被“卡脖子”的前提下，满足业务对数据库的可靠性要求。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树使用数据库 创建和删除数据库31293 人正在系统学习中